make - 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: |
Paul D. Smith <psmith>![]() |
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.
|
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 | Priority | 5 - Normal | ![]() |
1 - Later |
Severity | 4 - Important | ![]() |
1 - Wish | ||
Summary | Suggestion 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 |
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.