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).
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.
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?
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* would make me a happy Configure hacker. :^)
--Brent Dax <[EMAIL PROTECTED]>
Perl and Parrot hacker
"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."
