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.
|