Personal opinion here: I think this would be a completely worthwhile feature addition to cmake, ccmake, CMakeSetup, ctest and cpack.....
CMAKE_COMMAND_LINE or CMAKE_ARGV could be a list variable filled with argc/argv from the main that launched the process. Why not? It wouldn't hurt anything. And would provide useful / use-able information. Might even be a way for some ambitious CMakeLists author to conjure up his own "--enable-my-favorite-option" support. :-) David On 10/28/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > > On 2007-10-28 20:55+0100 Alexander Neundorf wrote: > > > On Sunday 28 October 2007, Eric Noulard wrote: > >> 2007/10/27, Alan W. Irwin <[EMAIL PROTECTED]>: > >>> As I respond to issues with the PLplot CMake-based build system that > are > >>> reported by our users, I repeatedly find myself asking them to report > the > >>> exact cmake command line that they used as well as full output from > the > >>> cmake command. If from within cmake we could print out a string > >>> corresponding to the exact cmake command line, then that simplifies my > >>> request to them for a full bug report. > >>> > >>> Is it possible to obtain the exact command line used to invoke cmake > >>> from within cmake? > >> > >> I don't know if it's already possible or not but I would be very > interested > >> in the feature too. Helping user to use the build system is of > >> great interest. > >> > >> I think I would be useful to have the exact CMake command line > >> > >> 1) as a comment inside CMakeCache.txt > >> 2) as a CMake string var something like: > >> CMAKE_COMMAND_LINE > >> > >> Note that may be CMAKE_COMMAND_LINE should indicate > >> what CMake tool was used: cmake, CMakeSetup, ccmake etc... > >> > >> Should on of us file a feature request? > > > > Not sure how much this would help. > > > > If you use ccmake, you don't need to specify arguments at all. You can > later > > on run cmake or ccmake again and change variables (using ccmake or -D), > > actually several runs may be required. > > > > So the initial command line doesn't have to contain everything you might > want > > to know. I guess looking at the cache makes more sense. > > I agree ccmake is a more complex case since the user could use the CLI to > fiddle with the options that were specified on the command line. Also, > our > users could further obfuscate bugs by hand-editing the cache file. To > avoid > that ambiguity we ask for bug reports from cmake executed in an initially > empty directory. For that case the feature request makes sense (and would > also make sense for ccmake if we asked users not to fiddle with the > options > using the ccmake CLI when reporting bugs). > > I could also justify this feature at a philosophical level, a language > such > as C gives the user access to exactly what was specified on the command > line > (even though there are general ways to communicate with the C programme > other than the command line). Shouldn't cmake and ccmake do the same? > > If the CMake developers don't think this is worth the trouble, that is > fine. > I can always fall back to asking our users to send in the cache file with > their bug report. (Thanks for that reminder, Alex.) However, that file is > quite lengthy and filled with excess information compared to the nice > summary you get from a single string containing the cmake (or ccmake when > the options aren't fiddled with using that CLI) command line. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting > software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > _______________________________________________ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake >
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake