From kde-core-devel Tue Jun 14 07:58:54 2005 From: Vladimir Prus Date: Tue, 14 Jun 2005 07:58:54 +0000 To: kde-core-devel Subject: Re: Build system for KDE4 Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111873718716318 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