Reusing arguments¶
In certain scenarios, the arguments to a cmany
command can get a bit
complicated. To aid in such scenarios, cmany
offers two ways of storing
these arguments, so that they are implicitly used in simple
commands such as cmany build
.
Session arguments¶
You can store arguments in the environment variable CMANY_ARGS
. Then the
resulting cmany command is taken as if it were given cmany <subcommand>
$CMANY_ARGS <command line arguments>
. In the example below, the configure,
build and install commands will all use the five given compilers and two
build types, resulting in 10 build trees:
$ export CMANY_ARGS="-c clang++-3.9,clang++-3.8,g++-6,g++-7,icpc \
-t Debug,Release"
$ cmany c # 10 builds
$ cmany b # same
$ cmany i # same
The arguments stored in CMANY_ARGS
can be combined with any other
argument. For example, if you now want to build only the Debug
types of
the current value of CMANY_ARGS
, just use the --include-types/--it
inclusion flag:
$ cmany b -it Debug
or as another example, you can process only a single build tree via the
--include-builds/-ib
, say, icpc
with Release
:
$ cmany b -ib 'icpc.*Release'
Some arguments to cmany are meant to be used before the cmany subcommand. For
those arguments, you should use the CMANY_PFX_ARGS
environment variable
instead of CMANY_ARGS
. cmany will see commands given to it as cmany
$CMANY_PFX_ARGS <subcommand> $CMANY_ARGS <command line arguments>
.
Note
The values of the CMANY_ARGS
and CMANY_PFX_ARGS
environment
variables are always used in every cmany
invokation. To prevent cmany
from using these values, you will have to unset the variables:
$ unset CMANY_ARGS CMANY_PFX_ARGS
$ cmany b # uses defaults now
Project file¶
cmany
also allows you to permanently store its arguments in a
cmany.yml
file which should be placed alongside the project
CMakeLists.txt
. This feature is under current development and is not
ready.