[CMake] Is it possible to obtain the exact cmake command line used to invoke cmake from within cmake?

[David Cole]

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 <irwin at beluga.phys.uvic.ca> 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 <irwin at beluga.phys.uvic.ca>:
> >>> 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 at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20071028/90c90e4e/attachment-0001.html