[C++-sig] Linking issues with Boost.Python

[Niall Douglas]

On 18 Aug 2010 at 15:32, David Aldrich wrote:

> > I would strongly recommend that you use something more modern than
> > GNU make. Boost's build system is much better. The one I use is scons
> > (http://www.scons.org/) whose only main fault is O(N^2) scaling to
> > source file number, a problem they are in the process of fixing.
> 
> I take your point. Personally, I find makefiles very hard to maintain.
> In particular, our #include dependency management is indecipherable! I
> guess the obvious replacements are SCons and CMake. I will take a look
> at these. 

Yeah scons is particularly outstanding with handling dependencies, 
though it's exactly that which is introducing the O(N^2) complexity. 
It goes off and works out what they are for you as a default and then 
you can programatically override if you need to. Unlike other build 
systems, you really can program the build system down to a fine 
detail. Want some crazy build and dependency system which calls a 
series of munge scripts to auto-generate C++ and/or GLSL shader 
programs in a recursive descent? Want to build eight different 
versions of the same DLL each with slightly different configuration 
and slightly different name, and then get parent projects to choose 
the right binary to link against according to a set of heuristics? 
Want to have the build system fire up a copy of VirtualBox running 
some arbitrary operating system, compile some sources there checked 
out from the local GIT repo and push them into the local build? None 
of these are a problem with scons, mainly because scons IS python and 
anything python can do your build can do.

> Should one consider bjam?

As Nat said, bjam is the core of Boost Build but Boost adds a lot to 
it. I've always found it lacking in configurability personally, and 
like Nat I'm also not fond of its syntax either - much like CMake 
too. I will say though that bjam scales very well and has no issue 
with truly huge projects.

But as you might guess from my examples above, I program my build 
environment much as I program applications. Anything which saves time 
in the long run really, and for me almost all build systems which are 
100% OS portable don't cut it here. If it weren't for the O(N^2) 
scaling problem, I'd actually say it's the perfect build system 
unless you hate python. And certainly given we're in the C++ SIG for 
python it's hard not to naturally recommend it!

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.