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 cmake file in some directory. This causes problems with other tools. You will no longer be able to install a boost library with `cget install boostorg/hana`. 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. 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. If someone wants to distribute his library outside of boost, what about having the same patch system as for eg. Debian packages wrt. upstream?
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.
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. Your sentence [1] suggest that having a library top-level CMakeLists.txt is already granted. Raffi [1] 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."