[Qt-creator] Target refactoring

[tobias.hunger at nokia.com]

Peter Kümmel wrote:
> I wanted to add support for ninja, the 'make' replacement.
> CMake now can generate ninja build files.

Ninja support for now is a cmake feature for now, isen't it?

At least I am not aware of qmake supporting it nor the autotools. Of course
the generic project may or may not support ninja, too.

> First I did it like it is done for jom, but this way looks like a hack,
> so I tried to find a cleaner solution. As mentioned in the previous mail
> the idea is to split out the code which defines the build command.

Yes, we basically have the string "jom" override the command used to in a makestep.

That works well, since they both are basically different implementations of the 

For ninja this will most likely not work: I expect it to produce different output, etc.:-)

> I also had a look at the qbs branch because supporting qbs and make

Qbs does not use make at all, it combines the configuration system and the build
system, which cmake keeps separate (cmake doing the configuration, writing files for
the build system to process).

> is similar support make/ninja but I only saw the same intermixing
> of buildsystem/toolchain/makestep/project.

I actually like what we have now (and even more what I am currently working on;-):

We have a project, which does all the configuration system parsing (be it cmake,
configure.in, .pro-files or just a bunch of creator specific files for generic projects).

Then we have build configuration which contains all the information to build one specific
configuration of the project.

To build it uses a list of BuildSteps. Those are the commands that actually do the work.
The most important one we have there are (the different kinds of) makesteps, which
do the biggest chunk of the work at this time.

I leave out the targets here which are just a convenient way to group sets of build-/deploy-
and runconfigurations.

The tool chains are not that important: They just provide some additional information to
creator (how to parse the output for warnings and errors, some defines and include pathes set,
etc.). In theory it should also pass some information to the configuration system (cmake, qmake,
whatever), but that is not there yet.

Projects contain targets, but those are not that important in this context, they merely group
different sets of build-/deploy-/runconfigurations, so I'll skip those in this context.

> When the "Project" needs details about the build system we could add
> an interface from which all the information could be get, it's better
> than to hardcode all the details in several classes.

If I understood what ninja is about correctly, then we do not really care for the information
there: It is too low level for what we need and the ninja-files get generated by cmake anyway.

So the CMakeProject already gets the information we care about (which files are part
of the project, which Defines are in use, include pathes, etc.). The only thing we need to do is
to call ninja instead of make. That is just replacing one build step with another. The cmake
plugin needs to take care of this, but since cmake needs to produce the correct configuration
files for ninja (and not the normal Makefiles) it needs to know that you are going to use ninja
anyway.

What else do you need?

> Maybe my proposal doesn't fit into the current design but maybe we
> could find a solution which makes it strait forward to add a new
> build system.

I don't see what is hard right now, but then I never tried to integrate ninja, so I might
be wrong:-)

Best Regards,
Tobias

Tobias Hunger
Software Engineer
Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori