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