Subject: Re: [boost] Library Federation
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-08-12 07:16:31
On 08/12/18 00:18, Robert Ramey via Boost wrote:
> On 8/11/18 1:12 PM, Andrey Semashev via Boost wrote:
>> 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
> Right - that's what we all do regardless of whether one does it by
> "hand" or via b2 headers.
I think I might have phrased my previous reply not clearly enough. I
only symlinked `libs/log` and then ran `b2 headers` once, which created
`boost/log` pointing at `libs/log/include/boost/log`. So the only thing
one has to do is to put the library into the Boost tree somehow and then
he can work with Boost, including his new library, as normal.
>> 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.
Yes, I also have projects that require a special environment, and I have
scripts that set up that environment. I find that inconvenient because I
must remember to run the scripts before starting to work on one of these
projects and I must be careful to know which console has that
environment and which doesn't. With Boost, I don't have to do that.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk