mainmake - Support: sr #105005, translate pathnames to...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

sr #105005: translate pathnames to system-local formats to ease writing of cross-platform makefiles

Submitter:  None
Submitted:  Wed 04 Jan 2006 03:33:23 PM UTC
   
 
Category:  None Priority:  1 - Later
Severity:  1 - Wish Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  None

Wed 04 Jan 2006 04:56:34 PM UTC, comment #1: 

Make doesn't really do much of anything at all with directory/path separators.  There are a few specific places where it does, such as in the notdir function and creating $(@D) etc.  For the most part, though, make treats targets simply as strings and it stores them internally as strings.

I don't really see how something like you suggest could be possible without entirely reworking the internals of GNU make.  When, exactly, would you do the translation?  You can't just translate the entire command script, because not every instance of "/" is a directory separator.  The command script is shell syntax, and make doesn't parse it so make can't know which strings are expected to be files and which are something else.  Even if make DID parse the command script, there's still no way to know which arguments to a command are intended to be a filename and which are just text containing a "/".

The only way this could work is if you translated the automatic variables, like $@, $<, etc. and then (similar to the way vpath works) said that command scripts that used those variables instead of writing filenames directly will be automatically translated.  I supposed you'd need to provide a translate function that people could use in the command script for other pathnames.

But, even the above wouldn't work; what if your rule was something like:

   foo/bar: biz/baz
           dosomething $(subst o/b,a/z,$@)

? Now this will break because before you do the expansion you're changing "$@" from "foo/bar" to whatever VMS paths are, so the subst will not work properly.

Also, it's not clear at all to me that you CAN translate UNIX paths into VMS paths: it seems like VMS paths contain more information than UNIX paths, so where will that come from?  Maybe there are sensible defaults for the rest of the info (versions, etc.): I know virtually nothing about VMS filesystems.

Providing some kind of path translation function would be easy, but as you say it would be a lot of work to convert your makefiles to use it everywhere, and it would be error-prone since it would by necessity be a no-op on UNIX systems, so the only time anyone could tell if all the translations were done properly would be using it on a VMS system... which is not something everyone has lying around to test with.

Paul D. Smith <psmith>
Group administrator
Wed 04 Jan 2006 03:33:23 PM UTC, original submission:  

In Dr. Dobb's Journal, Jan. 2005 John Graham-Cumming wrote a very good article titled, "Cross-Platform Builds". In the article he provides a detailed example of a series of (GNU make) makefiles that will work under Windows (Cygwin recommended) and various flavors of UNIX. To do this he uses '/' in paths for widest support.

I have been trying to get the cross-platform makefiles to work on Cygwin, Linux and OpenVMS. Cygwin and Linux are fine. However, problems arise with the way OpenVMS defines a path; e.g. "[rootdir.subdir1.subdir2]file.c" (without the quotes). Therefore my suggestion: Would it be possible to modify GNU make to work with one kind of directory/path separator internally - like the '/' - then translate this to a platform-specific path (primarily for Windows and OpenVMS) before interacting with the filesystem?

Alternatively, how about adding a built-in function to do the translation? I prefer the first approach where the translation becomes transparent to the makefile author.

I'm not sure what implications this has on the rest of GNU make. If someone could point out any issues that need to be considered and/or addressed then I may take a look at it myself. Unless someone has a quick/clean solution already! :-)

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-01-04 psmith Priority5 - Normal 1 - Later
    Severity4 - Important 1 - Wish
    SummarySuggestion to ease writing of cross-platform makefiles translate pathnames to system-local formats to ease writing of cross-platform makefiles
2006-01-04 None Carbon-Copy- Added steven --DOT-- gould --AT-- stevengould --DOT-- org

Back to the top

Powered by Savane 3.13-cf05.
Corresponding source code