Michael G Schwern <[EMAIL PROTECTED]> wrote on 01/01/2005 07:38:57 PM:
> My bad. I left in a / when I unified the VMS tool_xsubpp(). Its better
> solved by changing $(XSUBPPDIR)/xsbupp to $(XSUBPPDIR)$(DFSEP)xsubpp.
I can confirm that this solution would be fine for VMS since
DFSEP contains an empty string as it needs.
> The only other difference is VMS had this:
>
> XSUBPPDEPS = @tmdeps
>
> and Unix had this:
>
> XSUBPPDEPS = @tmdeps \$(XSUBPP)
>
> I'm assuming that some fix was put into the Unix version and it was
> forgotten for VMS. It went in as part of a large, rambling change from
> the cfperl branch years ago.
I am trying to imagine what utility there is in having
a dependence on /unix/path/to/xsubpp inside the Makefile.
Perhaps if you were hacking on xsubpp it might be helpful, but
even if you were doing that I'd argue that your time would be
better spent starting off running the
perl Makefile.PL
command and not relying on a dependence upon xsubpp to trigger
your module/extension rebuilds for you. I could be missing
something here though (???).
At any rate the folloing patch to MM_Unix.pm does allow
for DBI 1.45 to build on VMS (with the two other patches
applied to MM_VMS.pm):
--- ExtUtils-MakeMaker-6_25_07/lib/ExtUtils/MM_Unix.pm;-2 Fri Dec 31 08:48:17
2004
+++ ExtUtils-MakeMaker-6_25_07/lib/ExtUtils/MM_Unix.pm Mon Jan 3 12:43:38
2005
@@ -3520,9 +3520,9 @@
return qq{
XSUBPPDIR = $xsdir
-XSUBPP = \$(PERLRUN) \$(XSUBPPDIR)/xsubpp
+XSUBPP = \$(PERLRUN) \$(XSUBPPDIR)\$(DFSEP)xsubpp
XSPROTOARG = $self->{XSPROTOARG}
-XSUBPPDEPS = @tmdeps \$(XSUBPP)
+XSUBPPDEPS = @tmdeps
XSUBPPARGS = @tmargs
XSUBPP_EXTRA_ARGS =
};
I have not tested that on Unix though.
Peter Prymmer
