$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-05-23 20:21:10
On Monday, May 23, 2016 at 6:23:06 PM UTC-5, Gavin Lambert wrote:
>
> On 24/05/2016 00:56, Paul Fultz II wrote:
> >> On the other hand, if you found the "root" CMakeLists.txt in build/
> >> or in cmake/ first, and then run the above commands from that
> >> directory, then they would work as expected.
> >
> > Except there is no way to know it is the ârootâ, except that it is
> > atthe ârootâ. Instead the user tells cget or cmake what the ârootâ
> > is instead of trying to guess.
>
> As you said, though, that complicates things if you're automatically
> building dependencies rather than the main project they requested.
> (Which I think I recall you saying was a feature of cget.)
>
> It seems to me that a reasonable heuristic is to use a CMakeLists.txt at
> the root if one is there; failing that, look in cmake/ and build/
> subdirs (in that order).
>
Perhaps, but I don't see a need to do that because libraries don't hide
there
cmake in another directory(not even boost libraries).
Also, it is somewhat bad practice to put the root in a
subdirectory(especially
when there could be cmake files in other directories) as it makes directory
scope confusing to understand.
Furthermore, with bjam you cannot have a root jamfile hidden in a
subdirectory, either. So there really isn't a precedent for this even with
boost.
> Having said all that, I'm dubious about using cmake to automatically
> build Boost library dependencies in the first place.
>
Well of course, there isn't really a cmake build for boost, right now.
> The way I
> typically use Boost (and I'm sure I'm not alone in this) is to either
> use the pre-built packages (for Windows or Linux) or if I need something
> newer, to use B2 to build the complete set of libraries myself and then
> point other projects at those pre-built versions, rather than to build
> individual sub-libraries for each project parent.
>
But then you have to handle the dependencies on your own, unless you use
bjam
all the way through.