On Thursday, May 19, 2016 at 7:30:07 PM UTC-5, Gavin Lambert wrote:
On 20/05/2016 10:55, Paul Fultz II wrote:
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.
This is a defect in cget, if it does not expect/allow CMakeLists to be in a subdirectory. They are never supposed to be in the output directory of cmake (which defaults to the current directory), after all, so you always have to tell cmake where to find them.
'hana/build' is not the output directory, it is the directory where the guidelines says to put the cmake file. It is confusing, I know. Also, there is no defect in cget. cget just calls cmake on whatever directory you give it. cget can also unpack a tar file and call cmake on that as well. It can also download a file, untar it, and call cmake on that as well. If a library decides to hide its cmake file, then the user will need to manually download and untar the file and call cget on whatever directory your cmake file is hidden in. This is not a defect of cget. If a library has chosen to hide its cmake files, then its very difficult for the tool to known what cmake is the entry point. Instead, it requires the user to find where the cmake is supposed to be at from either the readme or the documentation, and then explicitly call out to the tool with the directory where the cmake is hidden. Of course, the disadvantage of this approach is that the tool cannot automatically download dependencies, which is one reason among many why I am opposed to hiding cmake files in boost.