On 01/02/2015 08:16 AM, Peter Dimov wrote:
Bjørn Roald wrote:
However, "b2 stage" could by default have same effect as "b2 install --prefix=.", then you will get exactly what you want I think.
No, this is not what I want. I don't want two copies of the headers, one in include/boost/, and one in boost/ (that would be pretty stupid). I don't want a symlink include/boost -> boost (somewhat less stupid).
When I go somewhere inside the Boost source tree, and use b2 to build a target, and that target has #include
, I want b2 to create a link include/boost/shared_ptr.hpp -> libs/smart_ptr/include/boost/shared_ptr.hpp, and then to use <include>include, rather than creating a link boost/shared_ptr.hpp -> libs/smart_ptr/include/boost/shared_ptr.hpp and using <include>. . Note that this has nothing to do with staging or installing. The "headers" target is an implicit dependency. Even if I had a copy of the headers in include/boost/, b2 would still recreate them in boost/ each time I build something.
I agree that this would not be an issue if b2 used separate include paths for each library.
This has nothing to do with b2, it's just truthfully implementing a particular modularization design, and the question of the right design is fairly independent from implementaiton. I think the original rationale was that if you put 100 -I paths, then all your command-line become absolutely unreadable, blow up all log files, and possibly blow up command-line length limits, explicit or implicit, in OS and various tools. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com