[Boost-commit] svn:boost r49776 - trunk/tools/build/v2/tools

Subject: [Boost-commit] svn:boost r49776 - trunk/tools/build/v2/tools
From: ghost_at_[hidden]
Date: 2008-11-15 17:10:18

Author: vladimir_prus
Date: 2008-11-15 17:10:18 EST (Sat, 15 Nov 2008)
New Revision: 49776
URL: http://svn.boost.org/trac/boost/changeset/49776

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

Text files modified: 
   trunk/tools/build/v2/tools/common.jam |    35 ++---------------------------------     
   1 files changed, 2 insertions(+), 33 deletions(-)

Modified: trunk/tools/build/v2/tools/common.jam
==============================================================================
--- trunk/tools/build/v2/tools/common.jam	(original)
+++ trunk/tools/build/v2/tools/common.jam	2008-11-15 17:10:18 EST (Sat, 15 Nov 2008)
@@ -503,44 +503,13 @@
 #
 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" ;
     }
 }