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