Re: [boost] CMake - one more time

On Tuesday, April 26, 2016 at 11:03:26 AM UTC-5, Robert Ramey wrote:

On 4/24/16 2:49 PM, Paul Fultz II wrote:

...

...

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

...

...

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

javascript:> wrote: directory of build.

...

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

you set the toolchain?

Here's how the GUI works

a) it shows you a form with two fields on it. Project Source directory and desired destination build directory.

b) You fill in these fields and hit "configure". The gui asks you a couple of questions - when toolset you want and a couple more.

c) The CMakeList.txt in the source directory runs and produces output which includes a list of variables it couldn't resolve along with any message(STATUS ...) output. The variables are usually those variables marked "CACHE".

Ok, I tried out the GUI to see for myself. Its as horrible as you are describing. You can specify the compiler or a toolchain during the questioning step. You can also set variables, and this part is not clear in the gui. For example, if I want to build with warnings, from the command line I run `cmake .. -DCMAKE_CXX_FLAGS='-Wall -Werror'` and the project will be built with warning flags. To do the same with the GUI, you must first use the 'Add Entry' button to add the `CMAKE_CXX_FLAGS` variable before you configure. Then you can configure and generate, but the variable will no longer show in the gui because it is neither an option nor a cached variable. However, you can verify that the variable is set by running `ccmake` which will show the variable.

d) In my case I have a "CACHED" variable I call "static_build" which is a boolean variable. This shows up as an unresolved variable with a checkbox (because it's a boolean type). Other variables are related to boost - these are pathnames or file names.

e) Through the GUI I assign values to these variables then invoke "configure" again. This process is repeated until there are no unresolved variables

f) Then I hit "generate" and the Build project is generated. In my case this is an IDE project on the system I'm using. Note that I put extra code into my CMakeLists.txt so that the IDE project includes links to the header files. CMake seems to try to track dependencies but it doesn't add these to the IDE project. I understand why it has to be this way. In any case it's not a big problem for me.

g) This leads to the problem of the BUILD_STATIC_LIBRARY (or whatever it's called). If you include add_library(libname STATIC ...) in your CMake script - you can't create a shared library. Then there is the fact that it was really unclear where else this variable might get set (command line? - other CMakeList.txt). So my method is: 1) in the CMakeLists.txt - create a CACHED variable X 2) set X in the configure part of the GUI 3) make a small CMakeFunction which is like "if(X) set(LINK_TYPE "STATIC") elseif() set(LINK_TYPE, "SHARED") 4) then use add_library(library_name ${LINK_TYPE} ...)

Yes, but cmake provides `BUILD_SHARED_LIBS` to do the same thing, and it even gives a recommendation in the documentation on how to configure it. It says "This variable is often added to projects as an option()".

I'm aware you're going to see this as another example of "fighting the system" - and you're right. It's just that sometimes you have to fight to make the system work.

But how does `option(BUILD_SHARED_LIBS "Build shared")` not work?

The final result is a system which works pretty well. I don't have to remember anything. In fact it works much, much better than actually editing the IDE. To add new source file, I just tweak the CMakeLists.txt and regenerate the IDE.

I would say the exact opposite. The thing I like about cmake is that I can build my project with MSVC without ever needing to touch the IDE.

This could be seen as an endorsement of CMake. It's not - the above description doesn't really capture the fact that there is a lot of experimentation and trial and error involved. It's like training an ant to train a flee. One can just read the docs, know what to do, write an unambiguous script and expect it to work. All we can really do is "fix it up" by creating another level of abstraction on top. Unfortunately, Most of time, these higher level abstractions are made with the same type of thinking which leads to the original problem.

Usually when the abstraction level goes up, its because its managing more complexity.

Ambiguously defined rules, functions with side-effects, etc. etc.

I don't know what you are talking about. There is no ambiguously defined rules.