FWIW, M::B's ability to do exactly what I want, because it's all just Perl, never ceases to please me. :-P
David :-) On Fri, Jan 9, 2015 at 8:07 AM, <sisyph...@optusnet.com.au> wrote: > -----Original Message----- From: bulk88 > > I am not sure yet if I need to install it as site/lib/Config.pm. EUMM >>> distros works fine with -MVCConfig, I haven't tried Module::Build distros, >>> so I'm not sure if I will have to resort to site/lib/Config.pm yet. Also >>> config.h will need a 1 line patch or to be replaced with >>> site/lib/CORE/config.h since there is 1 setting in it that syntax errors on >>> VC. >>> >> >> Module::Build tests for and forbids overriding Config (related report >> http://perlmonks.org/?node_id=987651 ), >> > > M::B's capacity to make me want to vomit never ceases to amaze. > (Thanks for the info - I don't think I ever realised that. Probably > explains the EU::FC author's electing for the "ExtUtils" namespace.) > > so that means VCConfig will have install itself as site/lib/Config.pm and >> use an ENV var to control VC vs GCC. >> > > Agreed - if you want to accommodate M::B and it be can't be coerced into > using the alternative config file, then there's no other option short of > getting M::B fixed. > > That will also fix the problem of a EUMM makefile, if it regenerates >> itself, it looses the VC-ness because the regen run of EUMM Makefile.PL is >> missing the -MVCConfig . >> > > IIUC, that last problem would be avoided by setting $ENV{PERL5OPT} to > -MVCConfig ? > > Cheers, > Rob > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
