Re: [boost] trunk vs release

Subject: Re: [boost] trunk vs release
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-05-21 14:40:50

troy d. straszheim wrote:

> 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 boost.build 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.

That's subset of (2) above -- I think :-)

>> 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.

svn:externals in SVN allow you to have master copies of headers say in

        libs/thread/include 

and have a copy checked out into

       boost/thread

while making commits in boost/thread work, and commit into the master
copy. Disk requirements are a question, though.

>>> 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...

There are different issues of:

1. Permitting to create Boost 1.Frankenstein release including random
versions of all libraries, while somehow checking the requirements
above.

2. Permitting to have different version of the same library in such
combined package.

Probably some of those can be good for like boost.serialization
needing spirit 1.6 -- but I am not sure that use case is still
very important, and whether we have any other similar.

- Volodya