Re: [boost] CMake - one more time

On Apr 24, 2016, at 3:45 AM, Raffi Enficiaud wrote:

Le 24/04/16 à 00:39, Paul Fultz II a écrit :

...

...

[snip]

...

...

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.

Maybe there is a misunderstanding in the notion of package then. For me package is something you install on the system/global environment, or an isolated environment that is able to remain consistent.

That is what happens when I build and install boost, but I can’t easily remove the version(unless I installed it in a separate directory) if it later conflicts with another library. I could try to install over top of it with a new version, but there could be files from the previous version that don’t get removed and could cause problems. However, with a package manager I can remove the version of boost and completely replace it.

...

...

...

...

Also I can definitely see a problem in supporting another tool. What would happen to boost if cget is "deprecated”?

[snip]

...

...

...

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).

If you think that cget is the way to go and is paving the way for a better use of boost, why not just proposing it for integration to boost?

Well, first, its written in python. This is mainly to simplify distribution. Since, I am doing this in my free time, I don’t have a lot of time to prepare distribution for deb, RPM, homebrew, and windows, and I would rather focus my efforts on the functionality. Although some time in the future, I would like to write a C++ version. Secondly, it only supports cmake. Maybe once boost starts supporting more cmake, a C++ version could be integrated into boost.

I believe it needs some work and a consistent way of integrating libraries to cget should also be explained.

Yes, and it needs more documentation. I have had issues opened on features that were already supported. I hope to get to that sometime soon. What are you referring to “a consistent way of integrating libraries”?

...

...

...

...

[snip] 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

I was referring to the (wrong) doc from https://cmake.org/cmake/help/v3.0/variable/CMAKE_PREFIX_PATH.html

Yes, the doc here is not clear, because in find_libraries: https://cmake.org/cmake/help/v3.0/command/find_library.html#command:find_lib... It clearly shows using it as a list. So they are improving documentation.

...

...

...

...

[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 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.

Well, this is not CMake, but this would be a "boost2cmake" layer, that might be not as thin as I would like to see. You are and I am right: everything is possible up to the appropriate amount of effort.

...

...

...

...

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).

Fine, but I think that letting some behind is not a good thing neither.

Nope its not, so I would hope the community would take up the effort to integrate those libraries as well.

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