Re: [boost] CMake - one more time

On Apr 24, 2016, at 12:56 PM, Robert Ramey wrote:

On 4/23/16 4:04 PM, Paul Fultz II wrote:

...

...

On Apr 23, 2016, at 1:09 PM, Robert Ramey 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?

No - I just startup the GUI, set the directory of the source and the directory of build.

Does the GUI provide a way to set variables at configure time? How do you set the toolchain?

This is one think I really like about CMake. I did run the command line version once 4 years ago though.

I always use the command line. It seems like the GUI would be a pain setting up multiple build directories.

...

...

...

...

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.

There is one confusion here. THere is one type of person or task - building the library as either shared or static. Then there is the person depending on the library/headers in some other CMake project.

Yes, but I was explaining how cmake has several variables setup so you as a build script writer don’t have to handle all the different ways a user might want to build or install the library.

My concern has mostly been as a developer creating and testing the library.

I haven't really addressed the "user" or consumer. So haven't touched about implementing the "find" functionality for “mylib”

Its just not how a user might want to find the library after its built. It also affects how the user will want your library to find its dependencies when they want to build it.

...

...

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.

LOL - I don't undertake to fight the system - the "system" actually fights me.

No, to start with you have chosen to put the CMakeLists.txt in a folder where its not found by cmake, and define your own system to handle shared/static libraries instead of using cmake’s.

Actually, the problem is that people think there's a "system" when there isn't. It's really a grab bag of disjoint features which can be made to work. This can be and actually is useful, but it's a system with limited conceptual integrity.

The problem is a build system has to handle a large amount of variability and complexity. Cmake has ironed-out a lot of this variability through out the years(and Boost.Build does handle this well also). Newer build systems tries to makes things simpler but usually require me to modify the build script(this includes Qt) to make things work which I think is a major fail, and shows the lack of knowledge the newer build systems have in regard to the full amount of complexity a build system has to manage.

This makes it difficult and unintuitive to extend and apply to anything other than the "example" cases.

Of course it makes it hard or unintuitive to extend a system when you are going against it.

Attempts to extend the "system" end up layer even more confusion on top of whats already there. This looks like it "solves" problems but just makes thing more opaque, arbitrary and fragile. Quality has to be built in - it can't be added on.

I don’t think building abstractions on top of a mature system is problematic.