2011/2/8 Martin O'Brien <martin.matthew.obr...@gmail.com>:
> I've resisted the urge to patch, since I really don't want to be dependent
> on a custom version of CMake.

My idea was more like proposing a feature request + patch in order to make
the feature go in upstream CMake.

I cannot ensure it will but...

> As far as how many people would like it, I don't know, but my guess would be
> that most who were more familiar with configure or really anything that
> Getopt long-ish than CMake would probably find it more familiar.

this may be discussed by people listening to the list :-]

My opinion is that it's sometimes annoying to have several ways to do
something  (-D OPT=ON vs --enable-opt) but it can ease the transition
and/or some common place way to handle option on the command line.

> What I've done in the past in a few cases where people complained mightily
> (as well as pretty unreasonably, as this is hardly end of the world) was:
>
> -DCONFIGOPTS="--enable-<whatever> --verbose --debug..."
>
> AND/OR
>
> -DCONFIGOPTSFILE=<somefile which contained options, one per line>
>
> And then parse that/those (using a cmake module).  Very ugly, but they could
> usually handle that with much less complaining, and it also prevented
> potential conflicts with cmake '--' options.

I see.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to