[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #42260] posixpath, hostpath, commasp, spcomma needed for non-Unix O

From: John Malmberg
Subject: [bug #42260] posixpath, hostpath, commasp, spcomma needed for non-Unix OS
Date: Thu, 01 May 2014 22:32:58 +0000
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0


                 Summary: posixpath, hostpath, commasp, spcomma needed for
non-Unix OS
                 Project: make
            Submitted by: wb8tyw
            Submitted on: Thu 01 May 2014 10:32:57 PM GMT
                Severity: 3 - Normal
              Item Group: Enhancement
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 4.0
        Operating System: Any
           Fixed Release: None
           Triage Status: None



Most platforms that do not natively use a posix path syntax still support a
Posix syntax inside the C library for operating on path names.

As such for those platforms there is usually well known conventions for
converting paths between Posix and the host native syntax.

The file operations in the C library will typically work on both
Posix and Native paths.

This results in GNU make on those platforms being able to process dependency
patterns with either Posix path names and in the host native pathnames.

The action part of the recipes may require a specific pathname syntax
depending on if they are implemented as internal commands, ported Posix
commands or native commands.

If the built in rules and user written rules for a non-Posix platform could
have functions to do the conversions needed from Posix to or from Native, it
would allow Unix makefiles, which is the mainstream to be used with either no
or ideally less platform specific customization.

$(posixpath, hint, path) would force a list of paths to be in posix syntax. 
The delimiters between files can be host dependent on input and a space on

$(hostpath, hint, path) would force a list of paths to be in
the host native syntax.  The delimiters between files can be a space on input
and host specific on output.

For platforms that use posix paths, these functions will just return the

The hint parameter is host specific and provides guidance where needed on the
translation.  For example VMS has a different syntax when a directory is
referenced as a directory than when it is referenced as a file, which the
recipe needing the translation can pass as a hint.

These functions can not be considered to reverse each other as there are some
host to native translations that can not be reversed and some native to host
translations that can not be reversed.

To go along with these functions would be two functions that would
respectively replace spaces with commas and commas with spaces to allow easier
conversions than what can be done with the current subst function.

VMS currently modifies some of the make variables to use a comma instead of
spaces as a convenience for writing rules.  Running the GNU make test suite on
VMS shows that causes problems with using other make functions that are
require a space delimiter.

With the above functions added, that VMS specific hack can be marked for
depreciation and eventually phased out.

I considered setting these functions up as VMS specific.  However other
non-posix platforms could probably benefit from them.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]