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