Sometimes my own stupidity is hard to bear:
For days I had been fighting with ExtUtils::MakeMaker (admittedly a not so pleasant job). Imagine the scenario: A top-level Makefile.PL and a libdbx/Makefile.PL. To make the whole thing compile on some compilers you need to pass extra flags to perl Makefile.PL. According to the docs, I had to add
sub MY::pasthru {
my $self = shift;
my $ccflags = $self->{CCFLAGS};
return <<PASTHRU
PASTHRU = "CCFLAGS=$ccflags"
PASTHRU
}
to the end of my top-level Makefile.PL which sounded obvious enough to me. The rule to invoke libdbx/Makefile.PL had to be specified as well. So I added:
sub MY::postamble {
'
$(MYEXTLIB): libdbx/Makefile
cd libdbx && $(MAKE) $(PASSTHRU)
';
}
And yet, the CCFLAGS never made it to libdbx/Makefile. I checked the generated Makefiles that - according to my knowledge of make - should have done the job just fine...till I finally decided that it'd be more sensible to simply turn mad.
And why did it not work? Well, PASTHRU is not at all the same thing as PASSTHRU. Computers obviously have sharper eyes than humans. After correcting the typo in the above MY::postamble it all worked wonderfully.
However, the people naming this thing PASTHRU must have smoked something. There is no better explanation why they left off the second 'S' (reminds me of umount(8) and the creat() system call, two other crippled imbecilities).
Re:PASTHRU must have been done by...
ethan on 2003-01-17T06:48:25
... the same guy who locked in "referer" as the HTTP header.
I wasn't actually aware of this typo. That's probably even worse: Had I ever used this word in a non HTTPish context I'd surely have written it thusly instead of 'referrer'. Hmmh, looking at that, this spelling looks suspicious as well. Damn it!
