At the risk of making myself a target..... ;) Rather than looking for a build system where an IDE can manipulate the project file directly (eg .pro, CMakeLists.txt, etc.), is there any merit to defining an API or command line interface which an IDE can hook into and then it is up to the underlying build tool to support that interface? For example, an IDE would query the interface to get details about what's in the project. If the IDE then wanted to add a file, modify a flag, make some particular compilation feature conditional on a platform, etc., it would call a function/run a command and the build tool would then be responsible for carrying out the request. When the IDE wants to build a target, clean a project, etc, it would do that through the interface too rather than try to do it directly. The IDE would not have to be burdened with understanding the intricacies of the build tool's project files - that responsibility would then rest with the build tool itself - nor would the IDE even have to really be aware of whethe r something like make, nmake, msbuild, etc. is even being used under the covers.
There are a few of advantages to this approach: (1) Qt Creator and other IDE's can focus on their IDE, not the various build tools that they might want to support. (2) Developers would be free to use whatever build tool they liked as long as it offered a library/command line tool that fulfilled the interface. (3) Owners of a build tool would be free to continue using their existing project file formats or change them as they needed, without fear of breaking any IDE's that use the API/tool interface. They would just need to ensure that they provide an API/tool to fulfil the interface requirements. (4) The build tool owners should have the best knowledge for how to best take advantage of that build tool's features and strengths. They should be able to implement the interface in an optimal way rather than every IDE developer having to do that. (4) If anyone feels the need to write yet another new build tool, they could write the required library/tool for the IDE interface and then the IDE can use it with little or no modification. Using this approach, the whole argument of declarative versus imperative versus frankenstein-hybrid becomes a moot point. Instead, the discussion would shift to "what should be in the interface", and it's worth noting that the discussion here on this list is finally getting down to that anyway (at least qualitatively). I'm sure there are also disadvantages to this approach too, but I don't want to spoil the fun of those who would like to pick apart the idea. ;) Okay, warm up those flamethrowers...... it's cold enough here in Melbourne at the moment that we could use the heat. :-P On 09/06/2011, at 6:29 AM, Oswald Buddenhagen wrote: > On 06/08/11 20:39, ext Alexander Neundorf wrote: >> So what do you actually want from the buildsystem what cmake does not provide >> right now ? >> > hmm ... > > - it needs to be *fast* > > - a null build should not take noticeably more time than stat()ing all > files > - as thiago noted, it needs to handle distributed building efficiently > > these two boil down to not being a meta build tool, but a native > build tool. this is theoretically easily solvable, and the elusive > cbuild is being talked about since half a decade, but was still not > delivered. > > as far as i'm concerned, IDE integration should happen only via > native support plugins for The build tool. not sure how realistic > this is for the two relevant proprietary IDEs (VS and XCode). > > - changing a build rule somewhere deep down the tree absolutely must > not trigger a re-configuration of the entire build tree. > > - caching of build configuration should come naturally, not as an > afterthought (which many developers forget). > > these are inherent to the project structure and language. > > - it needs a language which is not a royal pain in the arse to use for > both humans and machines (IDEs) > > - it needs to be clean and well-specified > > - it needs to be declarative from the ground up: > > - the skeleton should be declarative. imperative constructs > should be clearly encapsulated - not the other way round > > - it should be declaration order independent > > - it should be centered around build properties, not command lines. > no CFLAGS, except as a total fallback. cmake is half way there. > > these are all prerequisites for a clean IDE integration, and for > comprehensibility of complex build systems. > > - it should cleanly support modularization. using another subproject's > artifact should be the same as using a known framework or something > "configure"d. subprojects should be cleanly detachable from the > superproject. > > - it needs to feed an IDE with a useful understanding of the project > structure (not some random foo.o targets whose existence the IDE must > divine out of thin air) > > - it should take the concept of qmake's debug_and_release to the > extreme (and do it right) - make multiple shadow builds for different > platforms and build configurations at the same time > > these are just a few i can think of right now. while some just a matter > of throwing some $$$ onto them, for others i must ask you whether you > honestly think cmake could ever deliver them without compromising > functionality and/or fragmenting the existing cmake ecosystem (*)? -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
