Subject: Re: [boost] [cmake] Pull request announcement
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-09-26 21:20:14
On 2018-09-26 05:02 PM, Raffi Enficiaud via Boost wrote:
> Sure, but you do not see the dependency graph in its full extent, and
> this is a good thing: you want to see your direct dependencies,
> because those are the ones that you directly manage.
> As soon as you (or any tool) start unrolling the chains of
> dependencies, it may becomes messy. By taking the previous examples --
> very simple I have to say -- you may not even be aware of the 2nd copy
> of library "Z".
To avoid to get into grid-lock in the discussion (similar to Peter's
argument) I'm assuming that each library manages its own dependencies,
and "installing a library" will imply resolving them. And indeed, if you
install any Boost library (apt-get, dnf, vcpkg, ...) these dependencies
will have been taken care of by some upstream package manager. So let's
consider this a resolved issue.
>> All I want is the ability to work on a Boost library project,
>> compiling it against some other prerequisite (versioned) libraries,
>> some of which may be part of Boost.
> Yes, I understand.
> Do you mind having the ones that are part of boost - but only the ones
> you need for working on your library - checked out/cloned on request?
I do. That's precisely the difference between your second use-case and
the one I added, and I have explained what additional situation that
would cover that aren't covered by the earlier ones.
> What I was saying before is the following. If I know that libX depends
> on libY, I can make it such that by cloning or setting up libX, I
> would like to get libY automatically.
Yes, I understand. I think that's a fine use-case to support, but it
shouldn't be the only one.
> If I need external libraries, I can specify them explicitly from the
> command line, or use facilities such as the cmake's find_package to
> get them from the OS or any other location.
> I am fine with:
> cmake -DLIB_GIL=ON -DLIB_JPEG_LOCATION=/some/path/on/disk
Yeah, and that's all I'm asking, only that rather than libjpeg I'd also
like to be able to find Boost dependencies (e.g., filesystem, core,
etc.) that way.
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk