----- Original Message -----
From: "Patrick LeBoutillier" <patrick.leboutill...@gmail.com>
To: "Sisyphus" <sisyph...@optusnet.com.au>
Cc: "David Oswald" <daosw...@gmail.com>; <inline@perl.org>
Sent: Sunday, December 04, 2011 8:34 AM
Subject: Re: Strategy for improving install success of Inline::CPP
Rob,
It looks to me like %config is populated with the actual contents of
the config file,
so $config{languages}->{$o->{API}{language_id}} will never exist at that
point.
Damn ... so my patch would have the config file unlinked and then re-created
*every* time a script that uses that config file is run. We don't really
want that to happen.
Looks like if the config doesn't contain the current language, you
need to recreate
it and try again. Then if it still doens't exist, give an error.
Yes, that's what I was hoping my patch would achieve - by checking in
advance whether the current language was in there or not.
But if it puts the cart before the horse, then it's of somewhat limited use
;-)
I'll try to come up with a patch for you.
Thanks - that would be good.
David's not the only one who has come up against this problem. I don't know
if your Inline::Java ever fails with cpan testers because of this, but the
Inline::Python maintainer has also been bitten by this.
That was why I stuck in a 'REWRITE_CONFIG_FILE' config option for module
authors to use in their test scripts - to force the re-creation of the
config file.
But like David says, while that (probably) solves the issue with the cpan
testers, the user may subsequently still come up against that
M19_usage_language error when he runs his own scripts.
One feels that, in this day and age, this issue should be handled a little
better than is currently the case.
Cheers,
Rob
