[CMake] Re: Parsing cmake command line parameters

[Gonzalo Garramuño]

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.


-- 
Gonzalo Garramuño
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy