Re: [boost] boost include directory question

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:
 > AMDG
 >
 > 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
 >> pain.
 >
 > Why is it a pain?
See above.>
 >>    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: 
http://lists.boost.org/mailman/listinfo.cgi/boost
 >