Build system for KDE4
ghost at cs.msu.su
Tue Jun 14 08:58:54 BST 2005
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.
>> > - 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:
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
>> > - 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.
>> > - 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.
More information about the kde-core-devel