Re: [boost] Radical idea for repository structure

From: Michael Caisse (boost_at_[hidden])
Date: 2007-09-18 11:53:27

Beman Dawes wrote:
>
> I would guess that almost everyone believes that it would be best if the 
> header files for each library actually lived in that library. Lots of 
> people have suggested we move to that organization. The showstopper has 
> always been to avoid requiring end-users and library developers to have 
> to many paths to their build system (bjam, IDE, makefile, whatever).
>
> So if I understand you correctly, you are suggesting that as long as we 
> can still provide end-users of releases with a single path (by copying 
> to boost-root/boost during release preparation), it might be OK to force 
> developers to do have to specify a path for each library their library 
> depends on.
>
> That strikes me as OK if they only have to specify direct dependencies, 
> which is something they control. But it isn't OK if they have to specify 
> indirect dependencies, which out of their control, much harder to 
> identify, change all the time, and are sometimes subject exactly what 
> macros are defined for a given compile.
>   

Unless I'm missing your point, this is exactly what boost.build/bjam are
good at. Developers specify the requirements and usage-requirements for
their project and/or rules. Developer of library A only needs to list the
project id and rule for dependency B. The developer of library A clearly
knows that they are using dependency B. Any usage-requirements for
library B are described in the Jamfile for library B. Developer A never
needs to track or worry about them.

<snip>

> See above. I don't see how it can work if a Jamfile has to be changed 
> every time its indirect dependencies change.
>
>
>   

The only time Jamfiles should be getting changed is if one of your
direct requirements or the usage-requirements of your library changes.
Indirect dependencies would be controlled by the usage-requirements of
the other libraries creating them.

-- 
----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com