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

 
 

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

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

Submitted by:  None
Submitted on:  Wed 04 Jan 2006 03:33:23 PM UTC  
 
Category: NonePriority: 1 - Later
Severity: 1 - WishStatus: None
Privacy: PublicAssigned to: None
Originator Email: -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>
Project 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

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 4 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Wed 04 Jan 2006 04:56:34 PM UTCpsmithPriority5 - 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
Wed 04 Jan 2006 03:33:23 PM UTCNoneCarbon-Copy-=>Added steven --DOT-- gould --AT-- stevengould --DOT-- org

Back to the top


Powered by Savane 3.1-cleanup