Wow. InlineX::C2XS is exactly what I want. Then I could reconstitute the
Devel::PL_ origargv as an XS module. If the author is unwilling, then I
could upload Devel::PL_origargvXS; not like that hasn't been done before.
Thanks. I'll keep you informed
On Friday, March 22, 2013, David Mertens wrote:
> What Rob suggested will work. Furthermore, if you manage to run your
> module like this during the build stage, you can use this approach to build
> your XS at build time. It'll work because the paths here are relative.
>
> However, due to cross-architecture concerns, Perl places binary module
> material in platform-specific directories. The approach Rob suggests
> side-steps this machinery and makes your module less robust. InlineX::C2XS
> is probably the better solution.
>
> David
> On Mar 22, 2013 4:51 AM, <sisyph...@optusnet.com.au <javascript:_e({},
> 'cvml', 'sisyph...@optusnet.com.au');>> wrote:
>
>> Hi Matthew,
>>
>> Like David, I'd probably go for using XS .
>> Unlike David, I'd use InlineX::C2XS to generate that XS file.
>>
>> If you really want to stick with Inline::C, something like this works for
>> me (on Win32):
>>
>> ##########################
>> package Some::FOO;
>>
>> BEGIN{
>> our $dir = $INC{'Some/FOO.pm'};
>> $dir =~ s/FOO\.pm\b//i;
>>
>> unless (-d "$dir/my_inline_build") {
>> mkdir "$dir/my_inline_build";
>> }
>>
>> };
>>
>> use Inline C => Config =>
>> DIRECTORY => "$dir/my_inline_build",
>> BUILD_NOISY => 1;
>>
>> use Inline C => <<'EOC';
>>
>> void greet() {
>> printf("Hello World\n");
>> }
>>
>> EOC
>>
>> $FOO::VERSION = 1.5;
>>
>> 1;
>> ##########################
>>
>> That will use the my_inline_build directory (which is located in the same
>> folder as Some/FOO.pm) for the Inline build directory.
>> And that will be the Inline build directory irrespective of what the
>> current working directory is.
>>
>> However, some considerations:
>>
>> 1) The my_inline_build directory needs to be in existence *before* Inline
>> is loaded. If it doesn't already exist, you could have
>> File::Path::make_path() create it (in the very same BEGIN{} block that has
>> determined the value for $dir). I've just used mkdir() as I know that's all
>> I need for my chose build directory.
>>
>> 2) The file path separator (in the above example it's a forward slash)
>> can change from one platform to another. That complicates things a bit when
>> it comes to examining %INC correctly ( and specifying directories) across
>> different platforms.
>>
>> Hope there's something there that helps.
>>
>> Cheers,
>> Rob
>>
>> -----Original Message----- From: Matthew Persico
>> Sent: Friday, March 22, 2013 3:27 AM
>> To: inline@perl.org <javascript:_e({}, 'cvml', 'inline@perl.org');>
>> Subject: Eliminating Inline
>>
>> Greetings.
>>
>> This is probably an RTFM, but I can't seem to find it in the FM.
>>
>> I want to use PL::origargv in the next version of Devel::ptkdb. I don't
>> want _Inline dirs all over the place for each person running the debugger.
>> I don't (for political reasons) want to set PERL_INLINE_DIRECTORY.
>>
>> What I want to do is force the _Inline for PL::origargv to be in
>> Devel:;ptkdb's installed directory tree when used by Devel:;ptkdb.
>>
>> Would my best bet be to cut n paste PL::origargv into Devel::ptkdb and
>> turn
>> THAT into an inline c consumer, setting and appropriate _Inline dir that
>> will be used by all?
>>
>> Could I get that dir created by the ptkdb installation somehow instead of
>> waiting for first use?
>>
>> Thanks
>>
>>
>> --
>> Matthew O. Persico
>>
>
--
Matthew O. Persico
