MCPcopy Create free account
hub / github.com/boostorg/build / variable_setting_command

Function variable_setting_command

src/tools/common.py:482–526  ·  view source on GitHub ↗

Returns the command needed to set an environment variable on the current platform. The variable setting persists through all following commands and is visible in the environment seen by subsequently executed commands. In other words, on Unix systems, the variable is

(variable, value)

Source from the content-addressed store, hash-verified

480
481# ported from trunk@47281
482def variable_setting_command(variable, value):
483 """
484 Returns the command needed to set an environment variable on the current
485 platform. The variable setting persists through all following commands and is
486 visible in the environment seen by subsequently executed commands. In other
487 words, on Unix systems, the variable is exported, which is consistent with the
488 only possible behavior on Windows systems.
489 """
490 assert isinstance(variable, basestring)
491 assert isinstance(value, basestring)
492
493 if os_name() == 'NT':
494 return "set " + variable + "=" + value + os.linesep
495 else:
496 # (todo)
497 # The following does not work on CYGWIN and needs to be fixed. On
498 # CYGWIN the $(nl) variable holds a Windows new-line \r\n sequence that
499 # messes up the executed export command which then reports that the
500 # passed variable name is incorrect. This is most likely due to the
501 # extra \r character getting interpreted as a part of the variable name.
502 #
503 # Several ideas pop to mind on how to fix this:
504 # * One way would be to separate the commands using the ; shell
505 # command separator. This seems like the quickest possible
506 # solution but I do not know whether this would break code on any
507 # platforms I I have no access to.
508 # * Another would be to not use the terminating $(nl) but that would
509 # require updating all the using code so it does not simply
510 # prepend this variable to its own commands.
511 # * I guess the cleanest solution would be to update Boost Jam to
512 # allow explicitly specifying \n & \r characters in its scripts
513 # instead of always relying only on the 'current OS native newline
514 # sequence'.
515 #
516 # Some code found to depend on this behaviour:
517 # * This Boost Build module.
518 # * __test__ rule.
519 # * path-variable-setting-command rule.
520 # * python.jam toolset.
521 # * xsltproc.jam toolset.
522 # * fop.jam toolset.
523 # (todo) (07.07.2008.) (Jurko)
524 #
525 # I think that this works correctly in python -- Steven Watanabe
526 return variable + "=" + value + os.linesep + "export " + variable + os.linesep
527
528def path_variable_setting_command(variable, paths):
529 """

Callers 1

Calls 1

os_nameFunction · 0.85

Tested by

no test coverage detected