Hello Rob,
Sisyphus wrote:
----- Original Message -----
From: "Reinhard Pagitsch"
[snip]
The fact that %Config::Config is a tied hash shouldn't make a
difference.
It seems that this does not work with my Perl version 5.6.1, because if
I use HvKEYS on config I get 0 keys.
The same happens with perl 5.8. I think this is a consequence of the tie
magic associated with the hash. I can't find any documentation relating to
HvKEYS(), but the documentation for hv_iterinit(), which also returns the
number of keys, specifically says:
Returns the number of keys in the hash (i.e. the same as "HvKEYS(tb)"). The
return value is currently only meaningful for hashes without tie
magic.
I find that both hv_iterinit() and HvKEYS() return 0 on both perl 5.6 and
5.8, yet the following Inline::C script indicates that the desired hashref
is being created and returned:
use warnings;
use Inline C => Config =>
BUILD_NOISY => 1;
use Inline C => <<'EOC';
HV * foo() {
HV * c;
char * a;
eval_pv("require Config;", FALSE);
c = get_hv("Config::Config", FALSE);
printf("No. of keys: %d\n", hv_iterinit(c));
return c;
}
EOC
$h = foo();
$k = keys(%$h);
print "No. of keys: $k\n";
print $h->{installsitelib}
__END__
I tried it also in an other way: creating a sub in my .pm file which
returns the value I want, and than call the sub from my XSUB.
But this is not what I want because on installing the module and runing
make test it will return the path where the perl modules are installed
and not the path where I am trying to compile the module. Therefor make
test will aways fail not finding the files which are located in the dll
directory.
Going back to the original problem, I think Jeff's solution is generally the
right one - this is something that should be sorted out when the module is
being compiled. But, as you point out, that makes problems when it comes to
making pre-compiled binaries.
Alternatives that I see (and there could be others):
1) Just do what Jeff said (maybe also provide binaries for all supported
languages if you want);
2) Modfiy your C structure to accommodate all supported languages (which is
originally what you wanted to avoid doing);
3) Break with any number of conventions.
As an example of 3), you could solve the 'make test' problem you mentioned
above by instead running:
perl Makefile.PL
make install
perl test.pl
Probably wouldn't go down too well with CPAN, CPANPLUS, and the cpan
testers.
That is a problem I want to avoid.
Is option 2) all that bad ? I'm not confident that I've got my head around
this properly, but it seems to me that option 2) should not be so bad.
Presumably the system gets queried to determine the language only once (when
the module is loaded, the result being stored in a variable) - so there's
not much overhead in that respect.
In my opinion option 2) is not the best way, because if I or an other
want to add a new language, modifications in the source code have to be
done. If all the strings are in different language dll's than I have
only to check if the dll exists and if not I can use a default language.
I also can provide a _template_ for a language dll which can be modifyed
and compiled by the user or someone other how want to add new language(s).
But this is only my mind.
cheers
Reinhard
