[Qbs] Unexpected behavior of MSVC generator

[Denis Shienkov]

Richard,

 > If you are using IAR then you probably appreciate the performant 
debugger and its ability to debug even highly optimized code. You are 
probably also used to IAR's editor and you can't live without it. Fair 
enough, but for that you don't need its native build tool, really. All 
you need is a project file generator that sets correct source files, 
defines, include paths and the application binary file path so that the 
IDE can understand it, invokes the debugger correctly and resolves code 
locations while debugging.

Yes, exactly! This is that I meant. :)

F.e. I want to use the QBS && QtCreator to compile my bare-metal 
project... e.g. for IAR compiler. But a main problem is that QtCreator 
has not the integration with the debuggers from the IAR. So, I will just 
generate the 'native' IAR project from the QBS project and to use the 
debugger from IAR IDE... Why not?

And then, perhaps I want to use the KEIL... Then I just will call the 
QBS to generate a 'native' KEIL project from the same QBS project and to 
open it from the KEIL IDE and to use its debugger and etc. Why not?


PS: F.e the CubeMX allows to generate a 'native' STM32 projects for each 
of IAR, KEIL and other IDE.

Why we can't implement similar features in QBS? :)


17.02.2019 0:48, Richard Weickelt пишет:
> Denis,
>
>>> What’s the point of implementing a rule for cpp files directly in the
>> solution and not implementing it for other cases? I don’t see any use cases.
>>
>> I'm don't understand a bit, what do you mean here?
> I think your view on the build process is too narrow. If all you care about is
> the conversion of C/C++ sources to object files to application binary, then it
> could make sense to produce native build files for your favorite IDE. This is
> all what proprietary IDEs with their little proprietary "build automation
> system" like IAR are usually capable of. But as soon as you want to
>
> - integrate custom tools in your build process, for instance code generators
>    (you mentioned already Qt moc)
> - build additional assests, like documentation
> - combine libraries and applications in a single build
> - parameterize parts of your project
>
> it becomes painful. Even for IAR users, additional code generators are not
> uncommon. The IAR IDE gives you the option to define one pre-build, one post-
> build action and ONE additional rule for a SINGLE tool. That might be
> sufficient in some simple cases, but as soon as you want to do more, you have
> to work around the IDE, for instance by invoking an external build tool.
>
> With the assumption that such cases are very common, it doesn't make sense to
> generate native build files at all. It is then often better and easier to let
> Qbs run the build process. I guess, this is what Ivan wanted to tell you.
>
>> UPD: I'm ask all this question, because I'm doubt: is it makes sense
>> tries to implement the generators (to spent a time) for a "bare-metal"
>> stuff... e.g. to generate the projects for IAR, Keil, Atmel Studio and
>> etc? Or QBS is dead, and we need to make tries to use CMake for that
>> cases (but I'm don't know and don't like CMake)? It is a main dilemma! :)
> If you are using IAR then you probably appreciate the performant debugger and
> its ability to debug even highly optimized code. You are probably also used to
> IAR's editor and you can't live without it. Fair enough, but for that you
> don't need its native build tool, really. All you need is a project file
> generator that sets correct source files, defines, include paths and the
> application binary file path so that the IDE can understand it, invokes the
> debugger correctly and resolves code locations while debugging.
>
> I think the same applies to the other IDEs you mentioned. Whether it makes
> sense to implement a project file generator is a different question. It could
> make sense if you are bound to one of those IDEs, but you want to build
> projects of higher complexity than what they can handle.
>
> Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20190217/5e5f2de8/attachment-0001.html>