Re: [boost] CMake - one more time

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

> On Apr 23, 2016, at 1:09 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> 
> 
>> 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.
> 
> LOL - I use the GUI

But don’t you still need to run cmake first before running the GUI?

> 
>> 
>>> 
>>> 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.
> 
> This statement is not about the particular CMake variable.  It's about the fact that the "language" has many, many builtin ambiguities which make it impossible to know or agree on how to use it.

What ambiguities? Cmake has several variables that the user can set to control how to build a project such as BUILD_SHARED_LIBS, CMAKE_PREFIX_PATH, CMAKE_INSTALL_PATH, CMAKE_CXX_FLAGS, CMAKE_CXX_COMPILER, etc. Cmake utilizes these variables when it builds targets, searches for dependencies, and installs components. These variables are documented as well. Furthermore, cmake is setup so you don’t have to think about these variables or implement the same infrastructure. For example, I can build a library like this:

find_library(FOO_LIBRARY_LIBS foo)
add_library(MyLib ${SOURCES})
target_link_libraries(MyLib ${FOO_LIBRARY_LIBS})
install(MyLib DESTINATION lib)

Then users can use cmake variables to build the library shared or static, set the prefix directory to search for the library, set the path where the library will be installed, set the compiler or compiler flags. Plus the above can be crosscompiled as well. 

> 
>>> 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.
> 
> Ahhh yes.  That's the real problem.  What you characterize as a solution/feather, I characterize as a symptom of fundamental fault.  Do have have to troll the whole net to differentiate a function?  Of course not.  That fact that this is now an acceptable answer is testament to the sad state of modern software development!
> 
>>> 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.
> 
> LOL - I'm referring to discussions such as this one.  The fact that everytime a question is raised, someone has an answer for some specific scenario.  This is deemed to be support that the system is a good one. This the exact wrong conclusion! It seems that it never occurs to anyone that the fact that such a question has to be ask in the first place is an indicator that something is fundamentally wrong with the concept and/or implementation.

Nope, the concept is fine. I think its best to actual learn how the tools are supposed to work instead of fighting the system.

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