From: Mattias Karlsson (Mattias.Karlsson_at_[hidden])
Date: 2006-03-14 03:43:44
A couple of questions:
Is there any support for partial linking of library targets?
Something along the lines of
lib foo : bar.c baz.c : <link>partial ;
A typical unix linker supports this by specifying "-r". Also, instead of
the usual ".a" archive you end up with another relocatable object file,
so the example above would generate foo.o, not foo.a.
Combined with a linker script (passed through <linkflags>) this can be
used to strip out unwanted symbols from a library that otherwise would
be included, which can speed up linking of large projects. It also
happens to be useful when the generated library is distributed to
customers, where we don't want internal symbols exposed.
How would I go about supporting c compilers that optimize across source
files? These typically fall into two categories:
Compilers that generate "fake" object files that contain an intermediate
representation of the source file, and delay actual compilation until
the link stage. One example is Intel's compiler (icc). Boost.Build
supports this easily by passing the correct command line options to the
compiler and linker, though it is quite easy to trip up by accidentally
inserting these fake object files into library archives.
Compilers that require all source code files presented to the compiler
at once. Two examples are gcc 4.1 (with the "-fwhole-program" option)
and the RealView ARM compiler ("-O3" enables multifile compilation). I
thought about creating empty object files and delaying the compilation
to the link stage as with icc, but I can't quite figure out how to get
all the source files to the link stage. Any (better) ideas on how to do
this with Boost.Build?
Thanks in advance,
PS: Boost.Build is a good deal better than any of the other alternatives
I've experimented with, so keep up the good work! :-)
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk