Subject: Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-05-19 19:43:59
On Thursday, May 19, 2016 at 6:12:07 PM UTC-5, Raffi Enficiaud wrote:
> Le 20/05/16 Ã 00:55, Paul Fultz II a Ã©crit :
> > On Thursday, May 19, 2016 at 5:29:14 PM UTC-5, Raffi Enficiaud wrote:
> >> Le 20/05/16 Ã 00:09, Paul Fultz II a Ã©crit :
> >>> There is already library's that do this(such as hana and compute),
> >> This is not an argument.
> >>> so there
> >>> hasn't been a technical problem with the tooling.
> >> Nobody said there is one, people rather said there is no technical issue
> >> in having your CMakeLists.txt in ./build or ./cmake or ./anyothersubdir
> >> (something that you seems to omit quite often).
> > Yes there is a technical as well as a usability issue with hiding the
> > file in some directory. This causes problems with other tools. You will
> > longer be able to install a boost library with `cget install
> > Instead the user will have to manually download the repo, unpack the
> > archive,
> > and then do `cget install hana/build`. I find that unacceptable.
> To be honest, I do not care at all about cget. I would like rather to
> see cget support another way of working.
Why? Why can't a boost library support the standard cmake workflow?
> In terms of hiding, whether it is at the top-level directory or any
> subdirectory does not change much: it is buried deep down in a big tree
> in both cases.
What? If its at the top-level its not buried at all.
> If someone wants to distribute his library outside of boost, what about
> having the same patch system as for eg. Debian packages wrt. upstream?
They want to distribute their library through boost, but not through the
monolithic release. For example, I can download Boost.Hana here:
This is directly from Boost.Hana's page. I don't know exactly what you are
talking about, and I don't think users of hana would know where to go to
download this patched release.
> > Library authors who support cmake do not want their support treated as a
> > second-class citizen.
> Yet, the primary focus of a boost library is not its good cmake support.
It is for hana.
> >>> However, we would like the
> >>> wording in the guidelines to state in a more explicit manner that this
> >> is
> >>> acceptable in order to avoid possible future problems.
> >> There is an *IF* missing there.
> > Where?
> At the very beginning: *IF* there is some agreement (I am not in a
> position to say what is an agreement) and the policies are changed
> according to what you want.
Yes, of course, that is what we are asking for.
> Your sentence  suggest that having a
> library top-level CMakeLists.txt is already granted.
No it doesn't.
>  Sentence: "However, we would like the wording in the guidelines to
> state in a more explicit manner that this is acceptable in order to
> avoid possible future problems."
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk