On Sep-19, Brent Dax wrote:
> Steve Fink:
> # > Following things were done:
> # > - s,/,\${slash},g
> #
> # Ugh. How difficult would it be to have Configure do this rewriting
> # automatically? (Or rewrite to whatever it is you need, instead)? This
> # just clutters up the makefiles a little too much, IMO.
>
> Well...
>
> It's theoretically possible. However, it'll cause problems if we use
> tools that require use of slashes on arguments (xcopy /e, for example,
> which we might use to install modules at some point--and my
> understanding is that VMS tools all use slashes exclusively).
Good point.
> Either we substitute before we interpolate things into the Makefile,
> which'll miss any interpolated slashes (like the ones in the variable
> that defines which PMC classes are compiled in), or we do so after,
> which will hit all interpolated slashes (including command-line
> switches). We can't have it both ways.
I'm not so sure about that.
> But VMS brings up another point--can we afford to use a simple
> substitution at all? After all, they use a completely different syntax
> for paths, right?
Yeah, they have all kinds of wacky things built into their paths.
Although ${slash} may handle most of it, as long as you're only doing
relative paths.
> What seems far more promising to me is something in the cc wrapper we're
> using. Similar wrappers for ld, ar, and the other build tools might be
> in order. Nothing would please me more than a Makefile like:
>
> .c$(O):
> $(PERL) tools/build/calltool.pl cc $@ $<
>
> parrot$(EXE):
> $(PERL) tools/build/calltool.pl ld parrot$(EXE)
> $(O_FILES)
>
> That could appear exactly the same in makefiles/root.in as in /Makefile.
> All systems would use 'calltool.pl cc' to invoke the C compiler--it
> wouldn't be 'calltool.pl cl' on Windows, or 'calltool.pl gcc' on
> gcc-using systems. And 'calltool.pl' could convert paths on VMS or
> Windows.
That sounds promising. But I'm not sure how important it is for
root.in and Makefile to look the same.
What if we just used unix-style paths in the *.in files, as in your
solution, but explicitly marked all paths as paths? Then we wouldn't
need to build a new wrapper for every command that manipulated a file
not in the current directory.
I'm not sure what syntax to use:
${path $(LIBDIR)/foo/bar}
[[$(LIBDIR)/foo/bar]]
PATH[$(LIBDIR)/foo/bar]
&path($(LIBDIR)/foo/bar)
$path{$(LIBDIR)/foo/bar}
%path{$(LIBDIR)/foo/bar}
Let's try an example:
Current:
GEN_CONFIGS = include/parrot/config.h include/parrot/platform.h \
include/parrot/platform_interface.h \
include/parrot/has_header.h \
New:
GEN_CONFIGS = [[include/parrot/config.h]] [[include/parrot/platform.h]] \
[[include/parrot/platform_interface.h]] \
[[include/parrot/has_header.h]] \
Doesn't seem too bad.
