Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding'CMakeLists.txt'

Subject: Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding'CMakeLists.txt'
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2016-05-20 03:03:38

Le 20/05/16 à 05:33, Peter Dimov a écrit :
> Rob Stewart wrote:
>
>> cget could take the subdirectory as an argument and use it after
>> untarring, etc.
>
> No, because of its automatic dependency retrieval. Packages need to
> follow an uniform convention.
>
> Although it could in principle look into $DIR/cmake/ if it doesn't find
> $DIR/CMakeLists.txt.
>
> build/ is, however, totally nonstandard for CMakeLists.txt, so it
> wouldn't make sense for a generic tool to look there. There are
> libraries that have their CMakeLists.txt in cmake/, but I don't think
> that any have it in build/, as this seems to be the build directory by
> CMake convention.

Yet, the discussion about cget is totally irrelevant here ... boost 
libraries can just be considered as "upstream" libraries. If they do not 
integrate well with some package management or any other tool, then the 
tool should provide a technical solution without polluting upstream, 
like the patching system of debian or homebrew to name only those.

If the clear target of this post is to please cget, which is a tool and 
which is giving services to human developers, I believe this is even 
worse than the other branch of this thread that took the subject "Boost 
is supposed to serve *the entire C++ community; it isn't Boost's goal to 
serve Boost's community*".

I hope boost will not serve the cget community.

Raffi