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