As I see it, given your constraints, you could either monkey patch Inline
to do what you want, knowing full well that you'll have to closely follow
any developments to Inline (which seems to be pretty stable these days,
anyway), or if your project's C bindings are stable, you could copy the XS
files from the _Inline directory and create a bona fide XS module from it.
When you say that you can't set PERL_INLINE_DIRECTORY for political
reasons, do these reasons prevent you from setting
$ENV{PERL_INLINE_DIRECTORY} directly in the scripts that use Inline? That
would be a third and simplest option.
David
On Mar 21, 2013 12:28 PM, "Matthew Persico" <matthew.pers...@gmail.com>
wrote:
> 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
>
