----- Original Message -----
From: "David Oswald"
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.
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.
The first version to offer this is (the "devel") 0.48_01.
It won't be available in a "stable" release until 0.49 comes along.
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.
At least when that does happen, it's just a matter of doing as the error
message suggests - but it would be nicer if the issue never arose in the
first place.
I wonder .... in Inline.pm's sub check_config_file() we have the following
piece of code:
###########
$o->create_config_file($DIRECTORY)
if not -e File::Spec->catfile($DIRECTORY, $configuration_file);
###########
And, a bit further down in the same sub we have the following (which
produces the error message relating to the out-of-date config file):
###########
croak M19_usage_language($o->{API}{language_id}, $DIRECTORY)
unless defined $config{languages}->{$o->{API}{language_id}};
###########
Maybe we can fix this problem by preceding that first snippet with:
###########
# Make sure any existing config file gets removed if Inline doesn't
# already know about the specified Inline programming language.
# This will then hopefully ensure that a new config file (that
# includes the specified programming language) gets written.
unlink File::Spec->catfile($DIRECTORY, $configuration_file)
unless defined $config{languages}->{$o->{API}{language_id}};
###########
Here's the patch (against version 0.48_01 of Inline.pm) if anyone wants to
try it out:
#######################################
--- Inline.pm Sun Dec 4 04:33:04 2011
+++ Inline.pm_new Sun Dec 4 04:36:24 2011
@@ -728,6 +728,13 @@
}
}
+ # Make sure any existing config file gets removed if Inline doesn't
+ # already know about the specified Inline programming language.
+ # This will then hopefully ensure that a new config file (that
+ # includes the specified programming language) gets written.
+ unlink File::Spec->catfile($DIRECTORY, $configuration_file)
+ unless defined $config{languages}->{$o->{API}{language_id}};
+
$o->create_config_file($DIRECTORY)
if not -e File::Spec->catfile($DIRECTORY, $configuration_file);
#######################################
(This is, as yet, *completely* untested ... just something that struck me as
a possibility while I was looking through the Inline.pm code.)
Cheers,
Rob
