[CMake] Re: Parsing cmake command line parameters

[Bill Hoffman]

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