[cmake-developers] CMAKE_ARGC and CMAKE_ARGVx

David Cole david.cole at kitware.com
Thu Apr 28 13:49:29 EDT 2011


2011/4/28 Nicolas Desprès <nicolas.despres at gmail.com>

> 2011/4/27 Alexander Neundorf <neundorf at kde.org>:
> > On Wednesday 27 April 2011, Nicolas Desprès wrote:
> >> Hi,
> >>
> >> I'm experimenting with the variables available in script mode in the
> >> current master (a3a581f8cd):
> >>
> >> CMAKE_SCRIPT_MODE_FILE
> >> CMAKE_ARGC
> >> CMAKE_ARGVx
> >>
> >> Apparently they are not available in 2.8.4 yet.
> >>
> >> Using this test script:
> >>
> >> ##################
> >> message("Begin")
> >> message("CMAKE_SCRIPT_MODE_FILE=${CMAKE_SCRIPT_MODE_FILE}")
> >> message("CMAKE_ARGC=${CMAKE_ARGC}")
> >> foreach(i RANGE 0 ${CMAKE_ARGC})
> >>   message("CMAKE_ARGV${i}=${CMAKE_ARGV${i}}")
> >> endforeach(i)
> >> message("CMAKE_ARGV=${CMAKE_ARGV}")
> >> message("CMAKE_ARGN=${CMAKE_ARGN}")
> >> message("End")
> >> #################
> >>
> >> I have the following behavior:
> >>
> >> $ ~/build/cmake/git/_build/bin/cmake -P /tmp/test.cmake a1 a2
> >> Begin
> >> CMAKE_SCRIPT_MODE_FILE=/tmp/test.cmake
> >> CMAKE_ARGC=5
> >> CMAKE_ARGV0=/home/despre_n/build/cmake/git/_build/bin/cmake
> >> CMAKE_ARGV1=-P
> >> CMAKE_ARGV2=/tmp/test.cmake
> >> CMAKE_ARGV3=a1
> >> CMAKE_ARGV4=a2
> >> CMAKE_ARGV5=
> >> CMAKE_ARGV=
> >> CMAKE_ARGN=
> >> End
> >>
> >> I think the user does not care about having CMAKE_ARGV1=-P and
> >> CMAKE_ARGV2=/tmp/test.cmake
> >> I have attached a patch that do this behavior:
> >>
> >> $ ~/build/cmake/git/_build/bin/cmake -P /tmp/test.cmake a1 a2
> >> Begin
> >> CMAKE_SCRIPT_MODE_FILE=/tmp/test.cmake
> >> CMAKE_ARGC=2
> >> CMAKE_ARGV0=a1
> >> CMAKE_ARGV1=a2
> >> CMAKE_ARGV2=
> >> CMAKE_ARGV=
> >> CMAKE_ARGN=
> >> End
> >
> > I'm not sure I like this special handling.
> > See this example:
> > $ /opt/cmake-HEAD/bin/cmake -DFOO=TRUE -P test.cmake abc 123
> > Begin
> > CMAKE_SCRIPT_MODE_FILE=/home/alex/src/tests/cmakeargs/test.cmake
> > CMAKE_ARGC=6
> > CMAKE_ARGV0=/opt/cmake-HEAD/bin/cmake
> > CMAKE_ARGV1=-DFOO=TRUE
> > CMAKE_ARGV2=-P
> > CMAKE_ARGV3=test.cmake
> > CMAKE_ARGV4=abc
> > CMAKE_ARGV5=123
> > CMAKE_ARGV6=
> > CMAKE_ARGV=
> > CMAKE_ARGN=
> > End
> >
> >
> > I think it's ok to just hand all the arguments to the cmake script, so it
> can
> > look at everything and figure out what to do.
> >
>
> You score a point :-) But then command line arguments parsing starts
> to be tedious from the script point of view.
> Plus in your use case FOO will be set as a variable anyway so the
> script can picked it up from the cache. Actually, most of the cmake's
> options will have side effects of this type. Even the script name is
> made available as CMAKE_SCRIPT_MODE_FILE. The script will have to
> parse cmake's options that have already been parsed by cmake. I don't
> see any reason to pass these options to the script.
>
> Imagine something like that:
> $ cmake -DFOO=ON -Wdev --trace --debug-output --debug-trycompile
> --warn-uninitialized --warn-unused-vars -P test.cmake a1 a2
>
> I truely think the script writer don't want to hear about all the
> options before -P.
>
> --
> Nicolas Desprès
> _______________________________________________
> cmake-developers mailing list
> cmake-developers at cmake.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>


For these to be really useful, we should also introduce the notion of
arguments that CMake will ignore. (i.e. : put a "--" at the end, and the
stuff after that gets ignored by CMake, and only passed on to the script
itself.) For example, in the above case, a1 and a2 may well trigger a
command line error from CMake itself. Perhaps even after the script has
run...

I agree with Alex. If we are going to keep these variables and make them
useful, then they should contain the "argc" and "argv" from the C++ main of
CMake itself, so that the script can analyze them if it wants to. If it
doesn't... that's fine too, but at least they'll be there if somebody needs
to validate something based on them.

I think this feature should be considered an experiment, and possibly even
backed out of master and not put into the upcoming 2.8.5 release if there is
disagreement about how it should behave. There are other command line
nigglies that should probably be cleaned up anyhow before this is really
ready.

For example, consider the following (unusual, but possible) case and its
present behavior:

  cmake -DMyOption=ON -P script1.cmake -DMyOption=OFF -P script1.cmake
-DMyOption=Custom -P script1.cmake

Anybody care to guess what the output is, when script1.cmake contains
"message("MyOption='${MyOption}'")

:-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20110428/3a943243/attachment.html>


More information about the cmake-developers mailing list