Here's the concise version of the rest of the email:

 1) what is the best way to find the full name of the Inline config
    file?
 2) is there a better way to avoid this problem?

Thanks for any help, Doug

I've just updated my Inline::SLang module to use Inline::C during the
Makefile.PL to interrogate the S-Lang library (rather than have the C code
in an external file which had to be compiled, run, and the output parsed).
It's much simpler. Yay Inline. [If anyone is interested it's on CPAN at
  http://search.cpan.org/~djburke/Inline-SLang/
I'm talking about version 0.22]

So far so good. But that's because I already have an old version of the
module (ie Inline::SLang) installed on my system.

If I run it on a 'clean' set up then we get:

  - 'perl Makefile.PL' creates the _Inline/ directory, and adds to it
    a config file which knows nothing about Inline::SLang (since it isn't
    installed yet)
  - 'make' works
  - 'make test' fails because the config file was created before the
    system knew about Inline::SLang. I end up with lots of tests that look
    like

1..4
Error. You have specified 'SLang' as an Inline programming language.

I currently only know about the following languages:
    C, Foo, PDLPP, Pdlpp, foo, pdlpp

If you have installed a support module for this language, try deleting the
config file from the following Inline DIRECTORY, and run again:

    /home/doug/code/perl/Inline-SLang-0.22/_Inline

 at t/00init.t line 0
INIT failed--call queue aborted.
not ok 1 - Able to 'use Inline SLang'
#     Failed test (t/00init.t at line 9)
# Looks like you planned 4 tests but only ran 1.
# Looks like your test died just after 1.


The simple solution (it seems) would be for Makefile.PL to clean out the
config file from the "_Inline" directory on exit. However, I need a robust
way of determing what the name of this file is: I don't want to assume
it's called _Inline because some user will undoubtedly want to use a
different name. So is there a function in the Inline module that will
return me the name of the current config file?

Does anyone have suggestions for how to avoid this issue in the first
place or better work arounds than deleting the config file?

Doug

Reply via email to