[Qbs] Unexpected behavior of MSVC generator
denis.shienkov at gmail.com
Sun Feb 17 19:33:46 CET 2019
> 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 пишет:
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qbs