Subject: Re: [boost] boost include directory question
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-07-21 18:29:49
On 7/21/18 10:09 AM, Steven Watanabe via Boost wrote:
> On 07/21/2018 10:19 AM, Robert Ramey via Boost wrote:
>> The current instructions for doing boost development are approximately:
>> a) clone the boost super project from github.
>> b) invoke b2 headers which does one of:
>> 1) creates links in the boost root directory to individual projects
>> 2) or copies boost directories from individual libraries into the
>> boost root directory.
>> depending on whether it is a windows system or other system.
> That's not quite correct. b2 tries the following in order:
> - symlinks
> - junctions (windows only)
> - hard-links
> - copies
> Windows does support symlinks, depending on the
> version and permissions. As far as I am aware,
> junction+hardlink should work in Vista or later,
> so I'm somewhat surprised that you're seeing copies.
Here's a little more background.
I develop on a mac with OSX. I switched from windows some years for a
variety of reasons. I build and test with Xcode built from CMake. When
I think it's "done", I rebuild and test using B2. So I end in bin.v2
directories for clang and gcc several versions of each. Using
library_status I get a humongous table with all the test results sort of
similar to the boost test matrix but more fine grained. results are by
variant so there's a lot there.
So far so good. Now it comes to windows.
I installed Parallels. This loads a windows os on my mac-mini. A very
good product - really annoying and hateful company to deal with. After
the normal windows bs, install, updates, etc.... I've got an up and
running windows system on my mac. I do whatever it took to share my mac
file system on my windows "machine"
Now my windows wouldn't run until I blew away "something" root/boost and
maybe root/bin.v2 and invoked b2 headers.
Then my tests ran and every thing was OK. Now I have an even more
humongous table as it now contains all the windows variants as well
-debug/relase static/shared. Same thing for ubuntu linux development.
Unfortunately switching between these environments is sort of pain
subject to ... - I'm not sure. I'm sort of guess that the system has
some sort of "memory" hidden inside of bin.v2 but I don't really know.
Then there is the fact that I did this a more than a year ago and I
don't know that b2 hasn't changes. Actually I don't even know if b2 is
built on the debug or master branch or whether or not it makes a difference.
Oh - I use the master branch of Boost to do my testing so that I'm not
stuck chasing down everyone elses bugs in their libraries on the debug
branch. Occasionally, I pull the master branch. I have been running b2
headers when I do this. This seems to be necessary but again I have no
way of knowing.
BTW when I run b2 headers on my mac - it fails because it finds a bunch
of .DS files all over the place. I have to delete these by hand before
I run b2 headers.
Of course by now I've forgotten my original question. But I feel better
non the less.
> Also, if you're only building with b2, (part of)
> `b2 headers` is run automatically whenever you build
> your tests, so running it explicitly is rarely needed.
>> Since I test for both windows and other systems, this is somewhat of a
> Why is it a pain?
>> In considering my options, I'm wondering if specifying all the
>> boost library include directories in the CPLUS_INCLUDE_PATH
>> environmental variable (gcc compilers) or INCLUDE (msvc).
>> a) Has this been considered before?
>> b) Was it considered when the current system was setup?
>> c) Is there an reason why it wouldn't be a good idea?
> Do you really want to manage 100+ include directories?
> It's probably manageable for people who only use b2
> to build, but it's a lot more convenient for outside
> users to have a single directory.
I question this.
Suppose I have an app - sort of complex app which includes some boost
libraries, some libraries out side of boost. Since the app is pretty
big and complex, I've elected to build a lot it in the form of
"application" libraries to promote de-coupling of components and shorten
build times. The current system works but it requires the b2 headers BS
which unnecessarily polutes my file system with a 100 new include
directories. I would prefer to avoid this. In practice I would just
include the actual libraries I depend upon - thus reducing the brain
bloat. This alternative system would be good for including other
libraries as well such as experimental boost libaries, other libraries
entirely etc. I'd have the list of dependent libraries in one
convenient place. Also there are many cases where the dependency
changes. For example. If I'm going to run the library tests, I depend
on a bunch of boost while if I'm just building an app, I might depend on
a smaller set. If I forget to include a dependency, build fails rather
than just "automagically" get's fixed up without telling me a messed up.
Dependency could be build from the app or group of apps which constitute
the test suite.
Basically I don't like having my file system polluted with a bunch of
opaque magic files (or links or whatever).
>> Anyone with information on this is free to chime in. Actually anyone is
>> free to chime in.
> In Christ,
> Steven Watanabe
> Unsubscribe & other changes: