Subject: Re: [boost] CMake - one more time
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-04-26 12:02:45
On 4/24/16 2:49 PM, Paul Fultz II wrote:
>
>> On Apr 24, 2016, at 12:56 PM, Robert Ramey <ramey_at_[hidden]> 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".
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} ...)
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.
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.
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. Ambiguously
defined rules, functions with side-effects, etc. etc. So in addressing
the "problem" things are made better in the short run, but made much
worse as the system get's bigger.
This is why CMake - though it has many merits - is not a definitive
solution and why I believe is not a good replacement for Boost Build.
Now on to Boost Build .... LOL - just joking
Robert Ramey