22.04.2012, 12:52, "Peter Kümmel" <syntheti...@gmx.net>: > On 22.04.2012 10:20, tobias.hun...@nokia.com wrote: > >> Hi Peter! >> >> Great to see somebody working in that area:-) >> >> I am not sure having a "build system" is a necassary though since the >> "Project" already >> needs to know a lot about of details about the build system used. It needs >> to parse >> all the information we need to know out of the build system setup that >> defines the project >> after all. On the other hand you can argue that the project needs to >> understand the >> _configuration system_ used to decide which files belong to the project, >> which defines are >> used, etc. and not the low level _build system_ that actually decides which >> compiler/linker/moc/whatever calls are required to get the binaries you >> desire. >> >> So what do you want to archive with a new build system abstraction? > > I wanted to add support for ninja, the 'make' replacement. > CMake now can generate ninja build files. > > 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. > > I also had a look at the qbs branch because supporting qbs and make > is similar support make/ninja but I only saw the same intermixing > of buildsystem/toolchain/makestep/project. > > 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. > > 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.
Hi Peter, Are you planning to push your changes to Gerrit? -- Regards, Konstantin _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
