Boost logo

Boost :

Subject: Re: [boost] Library Federation
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-08-11 21:18:35


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk