Re: [boost] CMake - one more time

Subject: Re: [boost] CMake - one more time
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-23 18:39:48

> On Apr 23, 2016, at 2:12 PM, Raffi Enficiaud <raffi.enficiaud_at_[hidden]> wrote:
> 
> Le 23/04/16 à 19:19, Paul Fultz II a écrit :
>>> Yet, having the same output name in case you build twice led to an undefined behaviour (.lib gets overwritten), and is not natively supported by CMake (using eg. CMAKE_ARCHIVE_OUTPUT_DIRECTORY for making the distinction does not work alone).
>> 
>> Yes, thats just for windows, which would need special treatment.
> 
> Which is "just" one platform that is targeted, and "just" one use case not covered by what you propose.
> 
>>> You missed the "official" and "centralized" parts. apt/dpkg or yum are official and centralized package manager, cget is not. Why should it be official and centralized?
>> 
>> Bpm wouldn’t be official and centralized?
> 
> I do not know what BPM is.

https://github.com/boostorg/bpm

> 
>>> Because
>>> 1/ official is usually one, or at least all officials can work together (new Ubuntu for instance)
>>> 2/ centralized becase if we end up of having several package manager, then it is a mess (eg. apt for pip installed packages) as those do not communicate each other. Example: I have a pip python package compiled against openCV from the system, and then I update openCV on the system.
>> 
>> But thats the same problem with boost now. If a boost library depended on openCV and then the system updated openCV then the user would have to rebuild boost, however with some form of packaging system, it only needs to rebuild a small set of libraries.
> 
> Yet, we do not let the developer/user with the fake impression that he installed something in a good manner.

I don’t how it is different with cget or bpm.

> 
>>> Also I can definitely see a problem in supporting another tool. What would happen to boost if cget is "deprecated”?
>> 
>> Cget is open source. Also, its fairly non-intrusive, so it can be easily replaced by another tool if necessary.
> 
> There is a lot of open-source dead projects.
> 
> 
>>> Example: Fink/MacPort/HomeBrew.
>>> [snip]
>>> The part "It just requires a CMakeLists.txt at the top level" is by definition a layout requirement, which is in contradiction with the part "There is no layout requirements".
>>> Also the "(which all cmake-supported libraries have)" is not a requirement of CMake itself, it is just a "good practice”.
>> 
>> It is a requirement of cmake. If I call `cmake some-dir` then a CMakeLists.txt needs to be in ‘some-dir'. So then cget just clones the repository(or a unpacks a tar file or copies a directory on your computer) and calls cmake on that directory. There is no special layout requirements.
> 
> I know how cmake works. From what I understood, your requirement is to have a top level CMakeLists.txt. This is not a CMake requirement (as I can have references to a parent dir in my CMakeLists.txt).

Well cget doesn’t do anything fancy, it just calls cmake on the directory, if cmake finds CMakeLists.txt in another directory then it will be found(although I’ve never seen cmake do this before but its not very clearly documented either).

> 
>>> [snip]
>>> SAT solver, interesting... why would I need that complexity for solving dependencies? I see versions as a "range of possible", which makes (an possibly empty) intersection of half spaces.
>> 
>> SAT solver is what most package managers use to resolve constraints(such as dpkg).
> 
> I stay corrected. Yet this is something cget does not have.
> 
>>>>> What I am saying is that you delegate the complexity to another layer, call it cget or Catkin, or pip. And developers should do also the packaging, and this is not easy (and needs a whole infrastructure to make it right, like PPAs or pypi).
>>>> 
>>>> The complexity is there, which I hope tools like bpm or cget can help with. However, resolving the dependencies by putting everything in a superproject is more of a hack and doesn’t scale.
>>> 
>>> Right now it scales pretty well with BJam.
>> 
>> The fact I need to download entire boost to build and test hana using bjam seems like it doesn’t scale at all.
> 
> You made a point. But packaging is not the purpose of the boost superproject.
> 
>>> 
>>> What if we need conflicting CMAKE_PREFIX_PATH? eg one for openCV and another one for Qt?
>> 
>> CMAKE_PREFIX_PATH is a list.
> 
> Right, it was not the case in 3.0 apparently.

its a list in cmake 2.8 and 3.5

> 
>>> [snip]
>>>> I don’t know see how that is something that cmake doesn’t do either.
>>> 
>>> Let me (try to) explain my point with an "analogy" with templates vs overloads:
>>> 
>>> What cmake can do is:
>>> -------- declare possibly N combinations
>>> targetA(variant1, compilation_options1);
>>> targetA(variant1, compilation_optionsM);
>>> ...
>>> targetA(variantN, compilation_optionM);
>>> --------
>>> 
>>> and then consume a subset of the declared combination:
>>> 
>>> --------
>>> targetA(variantX, compilation_optionsY);
>>> --------
>>> with 1<= X <= N, 1 <= Y <= M.
>>> 
>>> 
>>> --------
>>> What BJam can do is:
>>> 
>>> --------
>>> template <class variants, class compilation_options>
>>> targetA(variants, compilation_options);
>>> 
>>> -------- and then consume any:
>>> targetA(variantX, compilation_optionsY);
>>> --------
>>> 
>>> with the same flexibility as templates: the instance of generating a version of targetA is defined at the point it is consumed.
>> 
>> I do not follow this analogy at all.
> 
> I felt smart when I made this analogy. And this is still the case :) BJam defines metatargets (or target functions) which is fundamentally different from simple targets: see here http://www.boost.org/build/doc/html/bbv2/overview/build_process.html. Properties associated to CMake targets are static. They may be associated with generating functions (https://cmake.org/cmake/help/v3.3/manual/cmake-generator-expressions.7.html) yet it is less powerful. I see it like
> 
> targetA(f(variants, compilation_options))
> 
> which I believe BJam can do (maybe with a less sexy syntax…)

I don’t see why you couldn’t create metatargets in cmake as well.

> 
> 
>>> If you do not see in what extent it is useful, please compare the overload vs the template approach in C++.
>> 
>> Cmake is a fairly dynamic language, so I don’t think it is as limited as you think.
> 
> We have diverging opinions. I am using cmake for more than 10 years now, I do not feel like I am missing some big part of it. I feel more like I am yet in the learning curve of BJam instead (although it would be a risky choice for my other projects... but this is interesting).
> 
>>>>> What I am saying is that it is indeed possible, I also know solutions,
>>>>> but this is not native to cmake.
>>>> 
>>>> Yes, its possible, and a module would help make it possible in a simpler way, although, I don’t know how common it is to group tests. In general, I usually just focus on one test or all the tests.
>>> 
>>> Tests was an example, and sometimes we end up doing things that are not common. At least I know that CMake or BJam do not tell me what to do, they offer the tools/language, it is up to me to implement it the way I need it.
>> 
>> Yes and the nice thing about cmake, is it leads you to a simple more modular design to solve the problem instead of trying to link in 20 different library targets that are a variation of shared and static from the same library.
> 
> I do not see any problem for boost, which is the scope here.
> 
> My opinion is this: *if* a CMake solution is "production ready" for boost, then let's continue the discussion. Right now, you exposed the "range of possible", while I tried to point out what is expected.

Well, I don’t expect to move the entire boost to cmake, that would be a very big mountain to move. Rather, some core libraries could start supporting cmake, and little by little more libraries can move to cmake. Most newer libraries already support cmake. Perhaps in the future, it would be nice to allow cmake-only libraries in boost as well(although won’t be in the main distribution).

> 
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost