Re: [boost] CMake - one more time

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