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

Reply via email to