Rodolfo Schulz de Lima wrote:
Alexander Neundorf wrote:
I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way
sets up the custom command line parameters.
There's a beauty in having everything inside CMakeLists.txt
Not only that, but this becomes a maintenance nightmare. It's too easy to get
these out of sync.
Or have a cmake modules, which handles this stuff, and which also
creates a custom target "help-args" or something like that, which
prints the available args. This would not be available before cmake
has successfully run.
This would be non-intuitive to people not accustomed to cmake.
This isn't a problem if it's documented well. If "cmake --help" spit out something told the user what to do, they will usually do it. The problem lies when the programs don't
behave as expected with no explanation (i.e. Using -DMY_VAR=value instead of -DMY_VAR:STRING=value should be rejected instead silently doing weird things).
Having a good README or INSTALL file does wonders. That's the first thing I
look for in a project.
I think that the scope of where argument definitions should be defined
should be well defined. The example I gave of each cmake --help
evocation returning a different set of arguments shouldn't be allowed.
But it's reasonable to create some arguments when cmake is running under
Windows or Linux, etc. And let's not forget that maybe 80% of all uses
of command line arguments will be the most trivial one, i.e., statically
define those arguments, so sticking with like 90% of all use cases would
be good enough, IMHO.
wxWidgets' configure script throws all possible options, whether they're
valid for Windows or Linux. It's really a mess, but it's simple to
implement and I've never heard of anyone complaining about it.
So this isn't so much a discussion of being able to parse arguments from the command line, but rather an automated mechanism to detect options in the CMakeLists.txt files and print
them out when a user does --help.
Many autoconf systems don't do this. To see the "real" options I have to scan configure.in myself. For autoconf build systems I have generated, I have to manually add the help
options. I think it's silly to try and solve this problem, especially when there is a much better way to do it via ccmake. I much prefer using ccmake than having the giant
configure line.
It seems like CMake already has a good way to configure builds, and those used
to autoconf just need a little nudging. I haven't had anyone in my group
complain about using ccmake.
That being said, if you really want cmake --help-options, then I guess you would just have to parse all the CMakeLists.txt files, find all occurrences of ADD_ARG() regardless of
scope, and spit them out. There really isn't a better option outside of just using ccmake.
James
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
