Re: [boost] trunk vs release

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

> 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
>> boost.build side)
> 
> Can we create some shared file? I think both build system can read&parse
> a file.

Sure.

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

-t