Gonzalo Garramuño wrote:
Alexander Neundorf wrote:
Yes.
In KDE we have the macro MACRO_OPTIONAL_FIND_PACKAGE(), which adds an
option around the find_package() call:
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/MacroOptionalFindPackage.cmake?revision=520790&view=markup
Beside that, it is really just a matter of syntax whether you do
--enable-build-this
or -DENABLE_BUILD_THIS=TRUE
No, it isn't *just* a matter of syntax (which is also horrible, btw). It
is also a matter of documentation. -DENABLE_BUILD_THIS is documented
nowhere. configure --enable-build-this is documented if you run it
without any flag.
But... what if we have this extreme case?
IF("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
add_command_line_parameter(whatever)
ENDIF()
So? You don't get the option if you don't run a debug build. As simple
as that. A better syntax for add_option would be:
add_option( NAME TYPE HELP [OPTS] )
with OPTS being:
CONFIGURATION "Debug"
REQUIRED "someotheroption"
That avoids the need for if-thens.
I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way
sets up the custom command line parameters.
Yuck!
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.
Yuck! Why wouldn't it be available? Have you guys used premake at all?
The premake.lua is ALWAYS read. If no parameter is passed, there's a
dry run of the file, and help with options get spit.
It is gorgeous.
Sure, lua runs 10 times faster than the cmake language does, but that's
a different story.
I don't think this has anything to do with speed. To find all the
options in a project you have to parse the entire project, no way around
it. The speed problem comes in because of try-compile/try-run stuff.
Just parsing cmake is fast. But, if we run the compiler 100 times then
well it has NOTHING to do with language! If we don't run all the try
stuff, then we can not accurately parse the while project as variables
will be set. The real answer is that the command line is a poor
interface to cmake projects. The new QT GUI is a much better way to go.
Due to the iterative nature of the cmake process running cmake once on
a project may run differently than running it twice on the project.
ccmake and the GUI's avoid this problem by not allowing generation of
projects until there are no new options. But, please, please stop
trying to make this a language issue!
-Bill
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
