Subject: Re: [boost] CMake - one more time
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-26 13:33:18
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 <ra..._at_[hidden]
> <javascript:>> wrote:
> >> 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?
>
> 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.