On Oct 8, 2006, at 5:49 PM, Ron Savage wrote:
o Just for the record, at $work, I checked several machines and
they all had 2
versions of Perl installed, but in each case I only checked the
compiler used
for the Perl I use, and in each case it was absent. This is a PITA,
of course,
and since I've been told to use the Perl /not/ in /usr/local/bin,
but in a
sub-dir of a commercial package I have to use, I'm constrained in
freedom as to
whether or not I install yet another Perl with it's compiler. Sigh
BTW, were you able to verify that the compilers that are available
don't actually work? I know the conventional wisdom says you
shouldn't even try, but in my experience it does actually work a good
percentage of the time. Compatible binary formats and all that.
Part 3: Enter a new Module::Build option, or similar
o I am thinking of some procedure the author, perhaps, could use to
generate the
info to add to the meta data, like so:
(1) Probe for compiler
(2) If found, remove compiler's directory from the path, and bugger
the
consequences (if only to forestall more red herrings)
(3) Go to (1) to check for more compilers
(4) Now, in a compiler-free environment, try to install the module
(5) If it installs, patch meta data to say so
(6) If the install dies, patch meta data to say so
(7) Ship module
That's an interesting idea but I think it's complicated enough that
it will be wrong just as often as a simpler "(1) does find_xs_files()
return anything" procedure. Whoever wrote such a tool would have to
know all the common names for compilers on various systems, too. And
my gcc is in /usr/bin, I don't really think much of anything would
work without that in the path. =)
-Ken
