[Qt5-feedback] Build system requirements for Qt5

[Alexander Neundorf]

On Wednesday 08 June 2011, 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.

There is absolutely nothing wrong if you write a replacement for make, a 
generator for that can be added to cmake.
 
>      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.

This is not possible with the cmake features as they are currently available 
with the current language.
There is the cache, which is project-global, and there are global properties. 
Both can be changed in subdirs, and propagate up to their parent directories. 
So doing something in a subdir can change what happens in the parent 
directory.

So with all current features enabled, a cmake run over the whole project is 
necessary after changing anything.

>    - caching of build configuration should come naturally, not as an
>      afterthought (which many developers forget).

What do you mean in detail ? 
 
>      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.

Others, e.g. Bill, can comment on that better than I can.

Just what I know: Bill seems to be open to add a second, declarative input 
format to cmake.
cmake was declarative when it was started, but became more and more 
imperative. E.g. when you say it should be declaration oder independent: 
add_subdirectory() was added because the order-independent subdirs() was not 
good enough for KDE.
 
> - 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.

By importing exported targets into a cmake project you what (I think) you 
want.
 
> - 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)

CMake can easily put all existing targets into the project file for the IDE, 
the IDE doesn't have to guess them.
 
> - 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

Don't know. Multiple build configurations in one build tree ?
If the build tool supports it, that's doable, this works e.g. with Xcode and 
VisualStudio.
With make, you need multiple build trees (which could also be integrated 
nicely in an IDE).
 
Alex