On Thu, Oct 23, 2008 at 06:25:12PM +1100, Sisyphus wrote:
> If, say, your Inline working directory is /home/david/.inline ... and you
> test Inline::CPP ... and after the tests have been run the config file in
> /home/david/.inline does *not* get cleaned up, then when you subsequently
> test PDL, the inlinepdlpp.t tests are bound to fail because that
> pre-existing config file (that the Inline::CPP tests wrote) won't specify
> 'Pdlpp'.
Inline::Pdlpp can reasonably expect users to also be using Inline::CPP.
The only time I would expect Inline::Foo to fall over because of
Inline::Bar is if Inline::Bar left some broken thing behind.
See my other messages for why that's not a realistic test.
> 2) Provide a separate Inline working directory for each inline-ish module
> that is tested.
That would probably require a patch in Inline itself - unless ...
> It looks like the next devel release of PDL might try to set the Inline
> working directory to a specific directory other than the
> PERL_INLINE_DIRECTORY.
But in the interests of avoiding duplication of work - and the
consequent bugs - it would be better if Inline itself did this, I think.
> However, I suspect that the PERL_INLINE_DIRECTORY
> environment variable might override that setting.
I would think you'd be OK. Simply wrap any access to Inline-ish things
in something like ...
{ local %ENV;
$ENV{PERL_INLINE_DIRECTORY} = catdir($ENV{PERL_INLINE_DIRECTORY},
'Pdlpp');
...
}
(you can localise %ENV, right?)
> [Ingy not handing over maintenance or doing another release]
Any particular reason why you don't think he'd do that?
--
David Cantrell | Reality Engineer, Ministry of Information
Longum iter est per praecepta, breve et efficax per exempla.
