[Qbs] Unexpected behavior of MSVC generator

Richard Weickelt richard at weickelt.de
Sat Feb 16 22:48:05 CET 2019


> > 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.


More information about the Qbs mailing list