[cmake-developers] CMAKE_ARGC and CMAKE_ARGVx

[Nicolas Desprès]

2011/4/28 David Cole <david.cole at kitware.com>:
> 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 like the "--" idea.

> 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.
>

That's the least risky option, indeed.

> 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.

I am very interested by this feature in the context of the generator
for Ninja. Ninja accepts only one command per rule contrary to make.
So when several commands must be called (for example: ar and ranlib),
one possibility is to bundle the commands in a cmake scripts and to
pass as arguments the value of $in and $out and other variables
containing flags so that the script can be reused for linking other
static libraries. If I cannot pass arguments to the script then I have
to generate one script per library hard coding every .o files and thus
generating one rule per library. This will work but Ninja is not
design for that. I have the same problem with the link.txt file.

>
> 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}'")
>
> :-)
>

That's a good one :-) But I think -P should be allowed only once.

I leave you guys the responsibility to take the decision, but I think
a behavior similar to others scripts languages like perl, ruby or
python would be the least surprising for the users. Have a look at
perl -h, ruby -h and python -h. They are addressing the same problem.

Thanks for your time,
Cheers,

PS: Maybe this topic should be tackled on the cmake mailing list to
gather more opinions from users.

-- 
Nicolas Desprès