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 _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
