Re: [boost] CMake - one more time

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

> On Apr 23, 2016, at 12:08 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> 
> 
>> This is not necessary at all. Cmake provides the `BUILD_SHARED_LIBS` variable that can be set to do this same purpose:
>> 
>> https://cmake.org/cmake/help/v3.5/variable/BUILD_SHARED_LIBS.html
> 
> Of course I saw this. This is a great example of the kind of thing that drives me nuts. looking at the CMake documentation
> 
> a) Its not clear how the variable is supposed got get set in the first place.  Is one expected to include in the CMakeLists.txt file a statement like
> set(BUILD_SHARED_LIBS TRUE)
> ?
> But wouldn't that constraint the build to shared or static library? What if you want to choose?

I would always set it at configuration `cmake -DBUILD_SHARED_LIBS=On` or in my toolchain file, which would be how I would set your `USE_STATIC` variable as well. 

> 
> b) What is the default? - oh it might depend upon whether "option()" is used somewhere.  Instead of providing an answer it just gives you another question.

You are right they don’t make clear what the default value is. The `option()` part is so that the user could set it in cmake-gui or ccmake, which is not the clearest in the documentation either.

> 
> c) So it is not clear on its face whether the statement add_library(target_name ....) builds a static or shared library.  It depends upon some other "global" variable.  That is you cannot know
> what a statement will do by looking at the statement.  Worse yet,
> the behavior of the statement may depend upon some higher level CMakeLists.txt file that you might not even be aware of.

The idea is that the user would set this(not the library author), so it shouldn’t be set in a CMakeLists.txt file.

> 
> d) is BUILD_SHARED_LIBS a cached variable?
> 
> I could go on, but you get the idea.  And this is just one single
> variable.  There are dozens with similar behavior and implications.
> As far as I can tell, all other build systems suffer from the same problems.  

Yes, but cmake has a much larger community that after a little googling I can find a solution to the problem due to the fact that there is a wealth of examples and tutorials out there.

> And the documentation actually makes it worse because it suggests that the system is simple to use when it's actually not.  It makes naive users feel like they're stupid - whether they are or not.
> 
> And this is made worse by the fact that there are lots of people who have made simple build scripts for small projects with limited requirements.  This work the first time - now they think it IS easy and they think there's nothing to it.  It's depressing.

I don’t know what you are referring to here.

> 
> One cannot make a build script without deep trolling of the net to find he cause of arbitrary surprises. You can't just read a build script and know what it does.
> 
> Robert Ramey
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost