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