Where is my XS Module located?

[Reinhard Pagitsch]

Hello,

Is there a way to get the path name where the dll is located?
e.g. the dll of my module is in
D:\Perl\site\lib\auto\Win32\File\Summary\Summary.dll

How can I get the path name, not in the .pm but in the .xs?
D:\Perl\site\lib\auto\Win32\File\Summary

Thank you,
Reinhard

[Sisyphus]

For the first part of the path, I find I can use any one of the following:
$Config{sitearchexp}
$Config{sitelibexp}
$Config{installsitearch}
$Config{installsitelib}
$Config{sitearch}
$Config{sitelib}

I think 'installsitelib' would be available and reliable on all Win32
machines.

Then that's followed by 'auto', which is in turn followed by the package
name split on the '::' .

Cheers,
Rob

[Reinhard Pagitsch]

Hello rob,

Sure, but what have I to do to get it in my XSUB? In a pure Perl
script/module it is no problem, but what are the functions I have to use
in my C/C++ function?

--
Antworten bitte nur an rpirpag at aon punkt at
Die Adresse im From/Replay to ist als Spamfänger gedacht und wird nicht
gelesen.
Please Visit: http://members.aon.at/rpagitsch/
An 100 Gewinnspielen/Monat teilnehmen:
http://www.gewinn24.de/index.php3?partner=1169

[Sisyphus]

----- Original Message -----
From: "Reinhard Pagitsch" <rp...@gmx.net>

[snip]

>
> Sure, but what have I to do to get it in my XSUB? In a pure Perl
> script/module it is no problem, but what are the functions I have to use
> in my C/C++ function?
>

Yuk .... I would probably have a pure perl subroutine perform the task, and
have the XSUB access that subroutine via a callback. (See the examples in
perldoc perlcall).

Perhaps there's a better way - if there is, I'm unaware of it.

Are you sure you need to do this ?

Cheers,
Rob

[Tassilo von Parseval]

It can be done from XS just as easily:

HV *config;
eval_pv("require Config;", FALSE);

config = get_hv("Config::Config", FALSE);

The fact that %Config::Config is a tied hash shouldn't make a
difference.

> Are you sure you need to do this ?

I am wondering about that myself, though.

Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);

[Reinhard Pagitsch]

Hello Rob,

No, not really. What I want to do is to make language dll's for
different languages (See my post "Otput for different languages").
But at this time I have no idea what the best way is.

regards,
Reinhard

[Reinhard Pagitsch]

Hello Tassilo,

Tassilo von Parseval wrote:
> On Tue, Aug 16, 2005 at 09:04:22AM +1000 Sisyphus wrote:
>
>>----- Original Message -----
>>From: "Reinhard Pagitsch" <rp...@gmx.net>
>>
>>[snip]
>>
>>
>>>Sure, but what have I to do to get it in my XSUB? In a pure Perl
>>>script/module it is no problem, but what are the functions I have to use
>>>in my C/C++ function?
>>>
>>
>>Yuk .... I would probably have a pure perl subroutine perform the task, and
>>have the XSUB access that subroutine via a callback. (See the examples in
>>perldoc perlcall).
>>
>>Perhaps there's a better way - if there is, I'm unaware of it.
>
>
> It can be done from XS just as easily:
>
> HV *config;
> eval_pv("require Config;", FALSE);
>
> config = get_hv("Config::Config", FALSE);
>
> 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.
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.
I hope I am clear enough?
I also tryed it with the Win32 API but than I have to have the handle of
the loaded dll to get the path where the dll is located and that is not
possible as I understand the API.

regards,
Reinhard

[Sisyphus]

----- 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

[Reinhard Pagitsch]

Hello Rob,
Sisyphus wrote:

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