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. Since I test for both windows and other systems, this is somewhat of 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? Anyone with information on this is free to chime in. Actually anyone is free to chime in. Robert Ramey
Am 21.07.2018 um 18:19 schrieb Robert Ramey via Boost:
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.
AFAICT this is no longer true: 1) Windows creates symlinks just like Linux (at least on my Windows 10 system, it does - even without elevated priviledges) 2) explicitly setting up the links is no longer necessary because it is done automatically when building Boost libraries. So, what is wrong with this approach? IMHO it is working just fine. Ciao Dani
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. 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?
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.
Anyone with information on this is free to chime in. Actually anyone is free to chime in.
In Christ, Steven Watanabe
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:
AMDG On 07/21/2018 12:29 PM, Robert Ramey via Boost wrote:
On 7/21/18 10:09 AM, Steven Watanabe via Boost wrote:
On 07/21/2018 10:19 AM, Robert Ramey via Boost wrote: <snip> 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. <snip>
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"
Okay. This makes things a lot more complex, as you're now accessing the filesystem from two different OSes which likely have different capabilities. It wouldn't surprise me if symlinks didn't work with this setup. I have similar issues with VMWare, but I've found that I can get around it by running `b2 headers` on the host OS before building anything on the guest. This works because the headers will be up-to-date in the guest, so b2 won't try to update them, thus bypassing the problem.
Now my windows wouldn't run until I blew away "something" root/boost and maybe root/bin.v2 and invoked b2 headers.
<snip>
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.
There's this: - symlinks supported : yes (cached) "cached" means that it's a result that was remembered from a previous run.
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.
That's annoying. b2 is just treating them as ordinary files which causes a conflict. If you tell me an appropriate glob pattern, I can exclude them. Or, perhaps, it would be better to use a glob for header names instead of assuming that all files are important. In Christ, Steven Watanabe
participants (3)
-
Daniela Engert -
Robert Ramey -
Steven Watanabe