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