Re: [boost] trunk vs release

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

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.

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.

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.

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

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

- Volodya