Rodolfo Schulz de Lima wrote:
Alexander Neundorf escreveu:
If you can find some spare time, there is a command argument
parser in CMake/Source/kwsys/, which is used e.g. by cpack, but
not (yet) by cmake. Using this in cmake is the first step in
getting better support for custom command line parameters. A
patch would be very welcome.
Currently I don't have the time.
I think I'll have some spare time to do this on this weekend, I'd
be glad to help if there's enough coordination to avoid
unnecessary work duplication.
Second idea: maybe it would already help if the command line
arguments to cmake would be available via a special cmake variable.
Is there anything which speaks against this, Bill ?
IMHO, we should differentiate between --enable/--disable and --
with/--without, like it is on autotools' configure. The former
used to enable/disable features, the other to compile with/without
some external library.
There's also the ubiquitous --prefix that should be mapped to
CMAKE_INSTALL_PREFIX, and the others that commonly appear when we
execute 'configure --help'.
It should be nice to have a framework to facilitate working with
enable/disable and with/without. The other common arguments that
maps to cmake variables should be set up by default.
The real problem with the command line arguments is how to gather
them up for a project. I really have yet figured out a clean way
to do that. People will want access to all options in the project,
but I don't see a way to do that...
-Bill
What is it that people want beyond -
DBUILD_THIS_THAT_WHATEVER:BOOL=TRUE could provide?
Do they want: --enable-build_this_that_whatever?
I also don't understand why we have to parse the whole CMakeLists.txt
structure. We should treat these command line args like we cache
variables like CPack does when you configure different builds.
James
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
