On Monday, May 23, 2016 at 6:23:06 PM UTC-5, Gavin Lambert wrote:
On 24/05/2016 00:56, Paul Fultz II wrote:
On the other hand, if you found the "root" CMakeLists.txt in build/ or in cmake/ first, and then run the above commands from that directory, then they would work as expected.
Except there is no way to know it is the ‘root’, except that it is atthe ‘root’. Instead the user tells cget or cmake what the ‘root’ is instead of trying to guess.
As you said, though, that complicates things if you're automatically building dependencies rather than the main project they requested. (Which I think I recall you saying was a feature of cget.)
It seems to me that a reasonable heuristic is to use a CMakeLists.txt at the root if one is there; failing that, look in cmake/ and build/ subdirs (in that order).
Perhaps, but I don't see a need to do that because libraries don't hide there cmake in another directory(not even boost libraries). Also, it is somewhat bad practice to put the root in a subdirectory(especially when there could be cmake files in other directories) as it makes directory scope confusing to understand. Furthermore, with bjam you cannot have a root jamfile hidden in a subdirectory, either. So there really isn't a precedent for this even with boost.
Having said all that, I'm dubious about using cmake to automatically build Boost library dependencies in the first place.
Well of course, there isn't really a cmake build for boost, right now.
The way I typically use Boost (and I'm sure I'm not alone in this) is to either use the pre-built packages (for Windows or Linux) or if I need something newer, to use B2 to build the complete set of libraries myself and then point other projects at those pre-built versions, rather than to build individual sub-libraries for each project parent.
But then you have to handle the dependencies on your own, unless you use bjam all the way through.