Re: [boost] CMake - one more time

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

...

On Apr 24, 2016, at 12:56 PM, Robert Ramey 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