I'll give your patch a try a little later this evening.
Another strategy I had resolved to try is this:
1: Patch the first test to run such that it calls the rewrite option
form Inline. I would do this both for CPP.pm and grammar.pm to
minimize sensitivity to the order in which test subdirs are recursed
into. This would resolve the smoke test issue.
2: Create a small module: Inline::CPP::Config, with the sole purpose
of executing code to trigger Inline to rewrite its config file.
3: Place a prominent note in the POD for Inline::CPP stating that in
some (or many) environments where Inline::CPP is being newly installed
it may be necessary to execute the following command as a final step
to configure the module:
perl -MInline::CPP::Config -e 1
'-e 1' is just a no-op. The meat and potatoes are that
Inline::CPP::Config would load and run the small amount of code needed
to ask Inline to rewrite its config file.
These would have to be against 0.48_1 dev, as I intend to use the rewrite flag.
All this because I'm convinced that it's impractical to convince
ExtUtils::MakeMaker to coerce Makefile to run such a command at the
end of the "make install" process. (If anyone knows how it could be
done, I could then eliminate step two and three from above).
Perhaps before I dig into implementing this sort of solution I'll wait
for additional feedback on how Inline.pm might evolve to better
facilitate the clean installation of plugins.
One question I have is this: I see that your patch just unlinks the
config file so that a new one will be written. Is that preferable
over rewriting the existing one? Or perhaps the two concepts are
synonymous.
This process (getting Inline::CPP back on its feet) has been more
dragged out than I had hoped, not only because of the config file
issue, but also because the CPAN testers site seems to be barely
limping along right now, and it's taking almost a week to get smoke
test results back. I'd like to get past these install issues so that
I can start moving on to my real plans, which include improving
Inline::CPP's test suite, and in the process hopefully discovering
areas where it is deficient so that I can start reigning in those
deficiencies.
Anyway, thanks everyone for taking an interest!
Dave
On Sat, Dec 3, 2011 at 9:50 AM, Sisyphus <sisyph...@optusnet.com.au> wrote:
>
> ----- 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
--
David Oswald
daosw...@gmail.com
