Nobody was "against" retaining it. The issue is that "-x" isn't an MCA
parameter, nor does it get translated to one under the covers. So the problem
was one of how to insert it into the typical MCA param precedence chain.
If we don't try to do that, but instead simply error out if both -x and the MCA
param are present, then that resolves the problem. However, and this is a big
"but", remember that there is no way to "unset" an MCA param. So if someone
puts the mca_base_env_list param into the default MCA param file, then there is
no way a user can put -x on the cmd line because the conflict will be detected
- and they can't turn "off" the MCA param to resolve it.
The inconsistent behavior may prove highly annoying in the user community, but
I don't know how widely used this feature will be.
On Jul 16, 2014, at 9:22 AM, Dave Goodell (dgoodell) <dgood...@cisco.com> wrote:
> On Jul 15, 2014, at 2:03 PM, Mike Dubman <mi...@dev.mellanox.co.il> wrote:
>
>> these are two separate issues:
>>
>> 1. -x var=val (or -mca opal_base_envlist var=val) will work in the same way
>> opal_base_envlist does the same as "-x" and can be used in the very same
>> fashion as -x
>>
>> 2. When list of vars is passed with help of opal_base_envlist, the escaping
>> is possible but escaped char should differ from delimiter char.
>
> That would be my preference (use something like "\" as the escape char).
> Though we could always go with a scheme where a doubled delimiter means
> "literal delimiter", sort of like "$$" in a Makefile.
>
>> I think -x should stay as shotrt-form alias for -mca opal_base_envlist
>> var=val and -mca opal_base_envlist var.
>> on dev meeting it was decided to deprecate it as some point.
>
> Can we revisit this decision? Mike and I both seem to be in favor of
> retaining "-x", at least for non-conflicting uses. Would someone who is
> against retaining "-x" please speak up in favor of that position?
>
> Also, Mike, I just looked again at the code and I don't think it is robustly
> checking for conflict cases. It's possible to do this and you won't get an
> error with the current code, right?
>
> ----8<----
> $ mpirun -mca mca_base_env_list foo=bar -x foo=baz ...
> ----8<----
>
> See this code, which only looks at the environment when looking for
> "mca_base_env_list":
>
>> Modified: trunk/orte/tools/orterun/orterun.c
>> ==============================================================================
>> --- trunk/orte/tools/orterun/orterun.c Tue Jul 8 20:10:04 2014
>> (r32162)
>> +++ trunk/orte/tools/orterun/orterun.c 2014-07-08 20:38:25 EDT (Tue,
>> 08 Jul 2014) (r32163)
>> @@ -1722,6 +1722,13 @@
>>
>> /* Did the user request to export any environment variables on the cmd
>> line? */
>> if (opal_cmd_line_is_taken(&cmd_line, "x")) {
>> + char* env_set_flag = getenv("OMPI_MCA_mca_base_env_list");
>> + if (NULL != env_set_flag) {
>> + orte_show_help("help-orterun.txt", "orterun:conflict-env-set",
>> false);
>> + return ORTE_ERR_FATAL;
>> + } else {
>> + orte_show_help("help-orterun.txt",
>> "orterun:deprecated-env-set", false);
>> + }
>> j = opal_cmd_line_get_ninsts(&cmd_line, "x");
>> for (i = 0; i < j; ++i) {
>> param = opal_cmd_line_get_param(&cmd_line, "x", i, 0);
>
>
> -Dave
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15173.php
