On Wed, Sep 03, 2003 at 11:07:25AM +0100, Orton, Yves wrote:
> BTW, I cant help wondering how many other things like this are possible
> booby traps. I somehow doubt that the extensions being built under Perl tax
> MM _that_ much so I think maybe some serious thought needs to go into
> considering what options should be set in init_main(). Id say off the cuff
> that _anything_ that is set in MM_SomeOS::init_others() should _not_ be set
> in MM_Unix::init_main().
Yes, this is a general problem in MakeMaker that I've had to be very careful
about.
The problem is we're using a single hash to store a many layered value.
The "default" set by MM_Unix (which is really MM_Base).
The OS specific value set by MM_SomeOS which should override the default.
A user supplied value which should override both the default and the OS
specific value.
The simplest way to fix this without rearchitecting is to store them
seperately and choose which to use when fetching. The MakeMaker
object would have to be tied.
The storage could either be done implicitly: "I'm in MM_Unix and on a
non-Unix OS so this must be the default value" "I'm in MM_Win32 so this must
be the OS specific value" "I'm not in the MakeMaker namespace so this must
be the user value" or explicitly:
$self->{_default}{LD} = $Config{ld} || 'ld';
$self->{_os}{LD} = $Config{ld} || 'link';
$self->{_user}{LD} = 'ld2000';
I kind of like the implicit idea. It means we don't have to go change all
the code, something I'd like to avoid.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/
You're smoother than a tunnel of shining sorrow.
