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