Build system for KDE4

[Vladimir Prus]

Chris Lee wrote:

>> >  - manual hints for dependency resolution
>> 
>> In another email it was said that something like:
>> 
>>    foo.cpp: fooui.ui
>> 
>> is needed. So far, uic support works without manual dependencies.
> 
> Also good, but in certain cases we might need to specify
> something that the build system doesn't automatically pick up.
> A fallback is necessary in those cases.

Point taken, though each specific case must be examined.

>> Supported.
>> 
>> >  - non-recursive (flat) builds
>> 
>> Not sure what it means. One can build in any directory, and only targets
>> in that directory will be updated (together with all dependencies).
> 
> Basically, it means that you don't spawn a sub-process for each
> subdirectory you enter. 

No, no subprocesses are spawn (except to compiler and linker ;-) 

> See the paper at: 
> http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html

Yea, I've seen it.

>> >  - --enable-final
>> 
>> What's this?
> 
> KDE builds support a configure option called '--enable-final'
> which concatenates all .cpp files (in one dir) into one
> foo_all.cpp file and compiles that instead of compiling each .cpp
> file on its own. It used to provide a significant compile-time
> speedup (not sure if it still does); it's not complicated to
> support, and it's a useful feature to make sure that we're doing
> header guards properly. Since we've supported it since ... well,
> forever, as far as I know, it's something we need in a replacement
> build system.

Point taken. Should be easy to implement. Should this behaviour be
also supported for Windows? After all, the de-facto compiler there is faster
than gcc.

>> >  - simple to the point of being learnable within 5 minutes
>> 
>> It's subjective, but a minimal file in a directory can contains just:
>> 
>>    lib whatever : whatever.cpp ;
>> 
>> >  - kdeinit support (?)
>> 
>> What's that?
> 
> Oh, boy. See http://www.suse.de/~bastian/Export/linking.txt -
> basically, kdeinit is a workaround for the fact that on most UNIX ..

Well, I know that much ;-) But how does this affect build system? 

>> >  - pkg-config support
>> 
>> Not supported, but should be possible.
> 
> We'll need that. Lots of the other things we depend on have been
> moving to pkg-config; even the X server is going that way soon.

Point taken.

>> >  - easily integrated into KDevelop
>> 
>> Good question. I intent to try this.
> 
> Well, this just means basically that we need a fairly limited,
> well-defined syntax for the build system instructions. Something
> like scons is a little hairier than something with a well-defined
> format that the KDevelop devs can build a separate parser for.

Well, Boost.Build files also use a fairly complete programming language, but
of course a small parsable subset can be defined. I'll need kdevelop
integration for a project of mine anyway, so I'll try to do something.

>> >  - 'admin' needs to be shipped in KDE instead of in src of each app
>> >    (if we keep the 'admin' dir, that is)
>> 
>> Should be doable. I'd expect that kde support will be just an single
>> module for Boost.Build, and placing it in any location where Boost.Build
>> can find it should be enough.
> 
> Yeah, shouldn't be hard as long as the build system is somewhat
> extensible and not completely static.

That's the case. Every project can do "import kde ;" and Boost.Build will
look for a module called "kde" in its search path.

>> On the downsides, Boost.Build does not have any support for config
>> checks, but I believe I can add them.
> 
> That would be very helpful.
> 
>> I clearly understand that no build system can work for KDE right of the
>> box, and will require tuning and optimisation, but Boost.Build might be a
>> good basic. Comments are appreciated!
> 
> Well, if worst comes to worst, we may just continue along the
> path of unsermake and replace whatever other parts we need to.
> It'd be much cooler if some $BUILD_SYSTEM_TEAM wanted to write
> the perfect KDE build system for us instead.

This is only possible with extensive feedback. What I can try alone is
building some small KDE subset (like kdevelop) with Boost.Build.


- Volodya