----- 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.
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.
Cheers,
Rob
