On 8/11/18 1:12 PM, Andrey Semashev via Boost wrote:
Just for the record, gcc has CPATH and not INCLUDE. clang, probably, too, though I didn't check. Syntax is probably different from MSVC's INCLUDE, too.
I'm aware of this. I just didn't want to get into all the details.
Also, I might be mistaken, but I thought there was a rather short limit on the env. variable length on Windows, which may come into play with variables like PATH or INCLUDE.
apparently its 8K on windows and something greater then 64K on linux.
I'm not quite sure what exactly you are proposing.
From my experience, when I was developing Boost.Log, I simply symlinked its tree into my Boost tree and had almost no problems with that setup. I didn't even have to run `b2 headers` whenever I added a new header to the library because `boost/log` was already a symlink to my `include/boost/log` directory. So in my case, this setup was mostly painless.
Right - that's what we all do regardless of whether one does it by "hand" or via b2 headers.
I'm sure I wouldn't want to construct a setup based on environment variables because, as I usually do, I wouldn't want to modify my default environment this way. This would affect my work with other projects. Which would force me to create a special environment for working with Boost, which would just add more hassle.
Actually this is a big part of my motivation. I work on multiple projects. Boost stuff, non-boost C++, embedded systems, and fiddling with non-boost libraries. These use different tools and different compilers - even if C/C++. So I have to have different environment, path variables, etc for each one. I have a system which maintains all these is a "project configuration file" so I can easily suspend work on one project and switch to another. Takes about 1 second. So for me this is a natural way to do things. Robert Ramey