On Tue, Jun 14, 2005 at 10:40:15AM +0400, Vladimir Prus wrote: > I would like to bring Boost.Build V2 (http://boost.org/boost-build2) into > the discussion. I might be biased, being the primary developer, but I think > the following feature list is pretty much covered. Neat. Haven't played with that (or even heard of it for that matter.) > > Must support: > > - generating binaries (duh) > > - generating shared libs (on all ELF platforms + MacOS X; Windows?) > > Yea, including OSX and Windows. Well, that's a good start. :) > > - icon installation > > Not sure. If this just entails copying icons to some install-prefix-relative > location, then there are no problems. Shouldn't be too much more complicated. The rules are a little weird in certain situations, but it shouldn't be too difficult to add to any build system. It's just one of those simple things that we obviously will need support for. > > - uic, moc, KConfigXT, etc > > uic and moc are already supported. KConfigXT can be easily added. That's a good start. > > - GCC visibility > > Not sure this is build system issue. Eh, I'm not either; it was mentioned in the discussion so I included it in the notes. > > - automatic dependency resolution > > Boost.Build has a global dependencies list (across all directories), and > there were no dependency issues. Right, that's good. > > - 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. > > - flex/bison > > 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. See the paper at: http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html > > - --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. --enable-final is more useful for packagers than developers, usually. (Also, we provide a 'make final' target in the subdirectories which does the equivalent of '--enable-final' but for each subdirectory. This would also be really useful, although I can't say it's an absolute must-have.) > > - builddir != srcdir > > Yes. Good. > > - 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 systems, the C++ compiler and the linker have sucked really badly for a long time, so loading a C++ program would require lots of redundant relocations as it figures out where all of the functions are mapped in the libs. kdeinit loads a whole bunch of KDE libs into RAM, and then forks KDE apps from them, which saves lots of relocations and makes app start times really fast. > > - multiple build targets (libfoo, libbar, libbaz) in one file > > Supported. > > > - --compile-slots, like in unsermake > > Is this "-j" that applies to compilations only? Yes, that's how -j works in > Boost.Build -- compilations are parallel, but linking is explicitly > serialized. Yeah. Basically, we want to be able to compile libbar while foo is linking. Not hard, but auto* gets it wrong. > > - 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. > > - support rpath sanely > > - ability to link & run uninstalled binaries > > I think this works. If you build, but don't install your project, you can > run all executables without problems, because paths to all libraries in the > project are added to rpath for the executable. On installations, > executables are relinked with rpath poiting to install locations (if > necessary). Good, good. > > - 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. > > - '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. > Another thing worth mentioned is already working support for DocBook (HTML > and PDF generation). That was something overlooked, good to know. > 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.