Quick intro: My name is Dave Oswald. I've recently accepted
co-maintainership for Inline::CPP.
I've been working on trying to improve the installation success rate
for Inline::CPP such that it will pass the same CPAN Testers smoke
tests that Inline::C is capable of passing.
Some history: Inline::CPP (prior to a few weeks ago) hadn't been
updated since around 2003. A number of issues had shown up in the
meantime that were causing it to fail to pass its own test suite, and
consequently, fail to cleanly install.
The first issue I tackled was dealing with the fact that as C++ has
modernized the standard has shifted from standard header files named
(such as) 'iostream.h' to simply 'iostream'. Given that Inline::CPP
hadn't been updated in quite some time before I started looking into
it, this shift in convention wasn't being handled correctly. I
believe that now we've got that resolved in a way that maintains
backward compatibility with older compilers, while also working well
with more current compilers that have implemented the newer standard.
At first blush it seemed that was going to be the main problem. But
then I've run into another one that, while various solutions seem
evident, I'm not sure quite what way to go. Here is a representative
example of the relevant output from one of the CPAN smoke testers:
--------------------------
Output from '/usr/bin/make test':
make[1]: Entering directory
`/home/trushel/cpan/build/5.10.1/Inline-CPP-0.31-vJhnsd/grammar'
make[1]: Leaving directory
`/home/trushel/cpan/build/5.10.1/Inline-CPP-0.31-vJhnsd/grammar'
PERL_DL_NONLAZY=1 /home/trushel/perl/perl5101/bin/perl
"-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib',
'blib/arch')" t/*.t
Error. You have specified 'C++' as an Inline programming language.
I currently only know about the following languages:
AS, ASM, C, Foo, GASP, NASM, as, asm, foo, gasp, nasm
If you have installed a support module for this language, try deleting the
config-x86_64-linux-5.010001 file from the following Inline DIRECTORY,
and run again:
/home/trushel/.Inline
------------------------------------
As you can see the configuration file from Inline::C hasn't been
overwritten, and doesn't mention CPP. I've talked to
syphilis/sysiphus about this via IM at PerlMonks, and he's offered
some good suggestions. But before I jump into making a change, I want
to make sure I'm making the right change.
One strategy I see (as suggested by syphilis) is to modify the first
test script in sequence such that it creates a "_CPP_TEST"
configuration directory, thus bypassing any existing configuration
file that doesn't mention CPP.
Another strategy (also suggested by syphilis) is to detect if
$ENV{PERL_INLINE_DIRECTORY} has been set, and if so, unlink everything
in its ./config* path. This seems rather draconian. What if the user
doesn't *want* his configurations deleted? :)
Along those same lines I'm told (and read in the Inline docs) that as
of Inline 0.48 there is the "REWRITE_CONFIG_FILE" option that can be
set. I suppose again I could put this at the top of the first test
script and get a clean install that way.
But I have concerns: First, it seems unhealthy to utilize a test
script as a means of configuring the module. Test scripts should
test. There should be some other means of finalizing the
configuration.
Second (and this is one that bit me, in fact): Just because someone is
able to get a clean install doesn't mean that the working, installed
version will have overwritten the working, installed configuration
files. What I mean is that it's one thing to overwrite the config
files for the test environment. But the same thing will need to be
done in the final installation environment. Forcing a config file
rewrite in a test script won't help once the module has reached its
final install destination.
Perhaps that second issue could be addressed by adding a blurb to the
Inline::CPP documentation explaining that once the module is installed
the user should force rewriting of the config file the first time it's
used. That seems like an awful kludge though.
Further reading material: syphilis's scratchpad on PerlMonks, where
he's been kind enough to toss out a few ideas (I hope he doesn't mind
my linking to it here):
http://www.perlmonks.org/?node_id=587490
If anyone has actually read this far and has some thoughts I'd love to
hear. I very much want to do the right thing here. And ultimately
look forward to getting past these smoke test issues so that I can
start to focus on the module itself.
Please let me know if you have any ideas of how to best deal with this issue.
Thanks!
Dave Oswald
daosw...@gmail.com
dav...@cpan.org
davido on PerlMonks
--
David Oswald
daosw...@gmail.com
