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.