Eric Noulard wrote:
2007/8/10, Bill Hoffman <[EMAIL PROTECTED]>:
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

_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to