I move this thread back into the user mailing list, because this is not promotion but interface design. Everybody would suffer if there are any errors in the command line interface organization!
On Monday 29 May 2006 19:38, William A. Hoffman wrote: > At 01:14 PM 5/29/2006, Axel Roebel wrote: > >On Monday 29 May 2006 18:01, William A. Hoffman wrote: > >> To work with the options, it is best to use ccmake or CMakeSetup, or > >> even cmake -i. To let people work from the command line we added the > >> abilitiy to use -DVAR=VALUE from the command line. What this does is > >> pre-load the CMakeCache.txt with the VAR. The VAR may or may not be > >> even used in the project, cmake does not care. To implement --help > >> correctly, you would have to configure the entire project first. My > >> suggestion was to create an extra file that could be parsed at --help > >> time, it would be small and easy to parse, and not require parsing the > >> entire tree. It would provide a map from VAR name to --commandline > >> name. It would be read by cmake and allow the project to specify its > >> options in one place, and make it easier to implement --help, and add a > >> way to specify a mapping from --option to a VAR name. > > > >Why not have the do nothing parser mode that displays all > >help strings of all options that are currently available? > >Together with the warning at the end of running cmake > >whenever the options did change, you would have all > >that is needed for command line operations! > > I suppose you could do this. I think there is still a need for some way > to map from cmake variables to more command line friendly versions. Even > if -help said you could do -DCMAKE_INSTALL_PREFIX=path, I don't think > it would make people happy. They will want --prefix=. My idea was that there would be the special short cuts that are most often used: --prefix=* -DCMAKE_INSTALL_PREFIX=* --verbose -DCMAKE_VERBOSE_MAKEFILE --build=* -DCMAKE_BUILD_TYPE=* and besides that --foo_bar=* always maps into -DTOTO_FOO_BAR=* It could be nice to additionally have --enable_foo_bar -> maps to the option FOO_BAR --disable_foo_bar -> maps to the option FOO_BAR > Maybe something like: > > set_variable_property(CMAKE_INSTALL_PREFIX COMMNAD_LINE_OPT "--prefix") I don't think a configurable behavior is needed here. It is my opinion that there is no need for freedom for these things. It is more important to create standards. It should be as easy to type and as standardized as possible! > There is also a logistics issue. The configure script is part of the > project. cmake is not. So, to get help for a project in the "do nothing" > parser mode, you will still have to tell cmake where the source tree is, > and where the binary tree is (in case cmake has already been run). It will > have to have the same options as actually running cmake. > > cmake --help ../path/to/source > or > cmake --help . (where . is a configured binary tree, or a source tree) I don't think it needs to be the same as configure. For out of source builds with configure you need to say ../path/to/source/configure --help or for in source builds ./configure --help from an ergonomic point of view this is basically the same with cmake having the clear advantage of being shorter to type then configure ;-) -- Axel Roebel IRCAM Analysis/Synthesis Team _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake