[Qt5-feedback] Build system requirements for Qt5

[Oswald Buddenhagen]

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 (*)?

regards

(*) bingo! :D