Hi, is there any way with cmake to know the compilation option if we are not online. I mean with configure, you can type “configure --help” and all the build option of the project are displayed. Is there similar feature with cmake?
I ask for that because I mainly compile ROOT on computers that do not have access to Internet.
Good question. There are two ways:
- The command ccmake will list you all the options and the possibility to set them in a GUI
- They are also documented in root.cern.ch/installing-root-source#options
Indeed, ccmake does the job.
I tried “ccmake” with “root-6.06.06” … after starting it, I pressed “c”, then modified the “all” setting to “ON”, then pressed “c” again … and “all optional components” were still not enabled (i.e. they all are still “OFF”).
Hi Pepe Le Pew. For some options this behaviour is intended. If you enable some option that requires additional packages, if these are not found, then the option turned OFF again unless the option ‘fail-on-missing’ option is set.
This is a clear bug … if I manually use “[c]cmake -Dall=ON” then it finds “optional components” … so, it’s just the “ccmake” which fails here (when I try to modify “all=ON” after the initial “configuration” step with the default “all=OFF” setting).
Let me explain better. The ‘all’ option switches on the ‘default’ value for a number options. When these options are defined they get set to the desired default value. Changing the ‘all’ option after the creation of the other options has no effect because they are already defined. You could delete all the options (D), then set ‘all’ and configure again to obtain the desired effect.
For my ccmake, “D” is not a recognized command.
And even it it was, if one deleted all options then also the “all” option itself would disappear (so you could not “change” it afterwards).
It seems to me that as soon as one sets “all=ON” (from inside of ccmake), ccmake should automatically set all dependent flags to “ON”, too. Then the next “c” (“configure”) step should detect which “optional components” can be realized and which cannot (and switch these “OFF”).
You can also try it the other way around … run “ccmake -Dall=ON”, then “c”, then change “all=OFF”, then execute “c” again … and it will NOT switch any dependent flags “OFF” (if they were already “ON”).
I guess a similar problem with ccmake will appear if one needs to set any “Something_DIR” or “Something_INCLUDE_DIR” or “Something_LIBRARY” variables. If one runs ccmake without these settings then this “Something” will be switched “OFF” (due to missing dependencies) and if one modifies the required variables from inside of ccmake then one will also need to remember to enforce “Something=ON” before executing “c” again (otherwise it will NOT reconsider “Something”).
Also here, I think as soon as one modifies any “Something_*” variable (from inside of ccmake), ccmake should automatically set “Something” to “ON”, too (for the next “c” command).
So, in the end … ccmake is not a very clever toy.
Sorry the command ‘d’ (lowercase) exists. Deleting all options, except ‘all’, that you can set to ON and configuring then does what I said.
Obviously the option ‘all’ is not very CMake-natural. This was introduced to allow a friendly transition from classic configure/make. Therefore ccmake might not be the ideal tool to play with it.
Typically the user do not need to set the variables “Something_INCLUDE_DIR” or “Something_LIBRARY”. By setting the the option ‘something’ the system should be able to locate the necessary bits and pieces. For that there is the help of the environment variable CMAKE_PREFIX_PATH and others. You only need to act of “Something_INCLUDE_DIR” or “Something_LIBRARY” if the system is guessing wrong of you want to do something special. So, I prefer to code automatisms for the most common and general case than for specific.