# from Capacio, Paula J
# on Wednesday 27 February 2008 13:39:
>>What is your `/opt/perl_64/bin/perl --version`
>This is perl, v5.8.8 built for IA64.ARCHREV_0-thread-multi-LP64
>(with 33 registered patches, see perl -V for more detail)
>Copyright 1987-2006, Larry Wall
>Binary build 817.1 [268662] provided by ActiveState
>...
>>and `uname -a`?
>HP-UX hxtapa12 B.11.23 U ia64 1871883104 unlimited-user license
>I believe I'm using an HP make utility; 'man
>make' shows that it does not have a version switch. This is what I
>could find out about it:
It looks like the weirdness is in make or somewhere in the interface to
it. You might want to ask activestate about it.
>>Finally, if the only test failing is compat.t, you would probably be
>>okay to just `./Build install` so long as you configure
>>your .cpan/CPAN/MyConfig.pm with 'prefer_installer' => q[MB].
>
>Naw...your statement "you might be on an architecture which hasn't
> been tested" makes me leery.
Well, if the only problem is in how the compat layer deals with your
vendor's make, any issues there can be definitively avoided by
configuring CPAN (and/or CPANPLUS) to not run Makefile.PL when a
Build.PL is available (and you could even delete Compat.pm from your
deployment if you like.)
One of the reasons Module::Build exists is that 'make' varies so much.
The compat layer is only there for people who are running an old
installation where their CPAN.pm doesn't know how to run Build.PL.
It would be dandy if you had a patch to fix the compat layer on that
platform, but in the absence of svn that won't be easy. The fact is
that nobody really *needs* the compat layer, especially if the CPAN
config is setup correctly.
--Eric
--
"Left to themselves, things tend to go from bad to worse."
--Murphy's Corollary
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
