Boost logo

Boost :

Subject: Re: [boost] trunk vs release
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-05-21 14:15:16

Vladimir Prus wrote:
> troy d. straszheim wrote:
>> Vladimir Prus wrote:
>>> FWIW, I expect Boost.Build mechanisms to be implemented shortly. However,
>>> to be fully sensible, it will require change of layout of libraries in SVN --
>>> otherwise we'll end up in a situation currently with CMake -- where there's
>>> 'modularize' command which changes directory layout to be different from
>>> that in SVN -- which is not a good idea in general.
>> But we can easily agree on what that layout should look like, and switch
>> both build systems simultaneously, right? Then we can do away with the
>> 'modularize' business. Let's do it!
>> Hm, wait:
>> 1. those who develop against checkouts of boost (not installed
>> versions) will need to define just what boost components they need. It
>> could get messy, but it has to be done.
> I am sure that folks who use either or cmake can be provided
> an easy way to get all components and their includes. However, we have 91
> libraries at present. Adding 91 includes path to command line seems like
> extremely bad idea -- it will overflow windows command line limit easily,
> and gcc only recently got response files support, so probably does not
> have it in mingw and cygwin.

I'm worried about the include paths too. Pondering modularization: It
isn't clear to me that e.g. 'flyweight' and 'util' need to be entirely
modularized. Maybe we could go coarser. But I'm not sure where I'm
going with this.

> Maybe we should review the goals of modularization? For me, its value
> is mostly that:
> 1. You can switch to a different version of a given library using single
> command.
> 2. It is possible to easily grab a subset of libraries.

I agree with these.... here's some specific cases:

- be able to play with proposed/sandbox projects without downloading a
zip file from the vault (crucial -- special case of 1.).

- be able to assemble a boost piecemeal... say you need serialization
and python.

> Maybe, we can still have single include directory while achieving the
> above goal if we make build process create symlinks to directories?
> That works on Linux, and I believe modern windows has some way to create
> links too. I am worried about other operating systems, though.

I share your worry. Probably some scm mechanism should take care of
it. I'm out of ideas for the moment.

>> 2. We'll have duplicated dependency information (see
>> libs/*/module.cmake... presumably there will be some analogue on the
>> side)
> Can we create some shared file? I think both build system can read&parse
> a file.


>> 3. We've said nothing about defining version-specific dependencies
>> (boost.spirit v.X depends on boost.proto >= v.Y)
> Do we even want to open this can of worms?

I'm not sure we do. Of course we are implicitly assembling these
dependency graphs as we do releases. It may actually be possible to
ferret out the details automatically by trawling through version
control. A nice project for a saturday night...


Boost list run by bdawes at, gregod at, cpdaniel at, john at