Re: [boost] CMake - one more time

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.