2
0
mirror of https://github.com/boostorg/build.git synced 2026-02-13 12:22:17 +00:00

Use \n, not various tricks that depend on eof style of common.jam itself.

[SVN r49776]
This commit is contained in:
Vladimir Prus
2008-11-15 22:10:18 +00:00
parent c549e85b34
commit c032e1be81

View File

@@ -503,44 +503,13 @@ rule copy-command ( )
#
rule variable-setting-command ( variable : value )
{
local nl = "
" ;
if [ os.name ] = NT
{
return "set $(variable)=$(value)$(nl)" ;
return "set $(variable)=$(value)\n" ;
}
else
{
# (todo)
# The following does not work on CYGWIN and needs to be fixed. On
# CYGWIN the $(nl) variable holds a Windows new-line \r\n sequence that
# messes up the executed export command which then reports that the
# passed variable name is incorrect. This is most likely due to the
# extra \r character getting interpreted as a part of the variable name.
#
# Several ideas pop to mind on how to fix this:
# * One way would be to separate the commands using the ; shell
# command separator. This seems like the quickest possible
# solution but I do not know whether this would break code on any
# platforms I I have no access to.
# * Another would be to not use the terminating $(nl) but that would
# require updating all the using code so it does not simply
# prepend this variable to its own commands.
# * I guess the cleanest solution would be to update Boost Jam to
# allow explicitly specifying \n & \r characters in its scripts
# instead of always relying only on the 'current OS native newline
# sequence'.
#
# Some code found to depend on this behaviour:
# * This Boost Build module.
# * __test__ rule.
# * path-variable-setting-command rule.
# * python.jam toolset.
# * xsltproc.jam toolset.
# * fop.jam toolset.
# (todo) (07.07.2008.) (Jurko)
return "$(variable)=$(value)$(nl)export $(variable)$(nl)" ;
return "$(variable)=$(value)\nexport $(variable)\n" ;
}
}