[CMake] --enable-* with cmake
Bill Hoffman
bill.hoffman at kitware.com
Fri Aug 10 09:41:25 EDT 2007
Eric Noulard wrote:
> 2007/8/10, Bill Hoffman <bill.hoffman at kitware.com>:
>
>> The process for configuring a cmake project has to be iterative because
>> options can
>> be nested inside if statements. ccmake, cmake -i and CMakeSetup all do
>> the following:
>>
>> 1. Configure
>> 2. Write CMakeCache.txt
>> 3. Did the CMakeCache.txt change ? Yes-> Go back to 1
>> 4. Allow the user to generate the project files.
>>
>> Given this, it will be impossible for a cmake project to ever automatically have
>> cmake --help.
>>
>
> I think I perfectly understand your point but I would
> say that adding "pre-parsing" phase where
> The main CMakeLists.txt "pre-parsed" in order to list
> the OPTION and their desc statement would indeed be feasible
>
> cmake -p would show INCONDITIONAL OPTION
> cmake -p -v may show ALL OPTION flagging those which
> may not be "resolved" without running CMake.
>
> I don't ask you (or Kitware) to do it
> since I personally don't NEED the feature.
> However, I wanted to note that it seems "possible".
> This may be an unwanted feature though if we wants
> CMake users to be fully "aware" of
> the CMake way of run you've described.
>
I still don't think it is possible. What about multi-projects. For
example,
in ParaView, it includes a complete copy of VTK. Both projects have
options, and all the options are not in the top level CMakelists.txt file
for the project. VTK also includes tiff, jpeg, and several other small
projects. CMake makes it very easy to combine projects. So, this
feature of parsing the top level CMakeLists.txt would only work for
very small "toy" projects, and fail on larger more complicated projects.
I suppose you could add a file at the top of a project that was something
like cmakeUserOptions.cmake, and the developer would be responsible
for making sure it was up-to-date with the rest of the project. But, I see
no reliable way to automatically figure out the list of options for a
project
until you run the code. Basically this requires a paradigm shift for
autotools
users. IMO, the CMake model is much more powerful as it scales to
very large code bases, and allows for easy additions of optional features
for a build. However, the price you pay is that you can not tell what
the options are until you run and interact with the project. Basically,
I and other CMake developers have given this a great deal of thought
in the past, and there really does not appear to be a good way to
do this... But if anyone can come up with a patch that is reasonable
and works on more than toy projects, I am willing to take a look... :-)
-Bill
More information about the CMake
mailing list