Eliminating Inline

[Matthew Persico]

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

[David Mertens]

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

Post by Matthew Persico
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

[s***@public.gmane.org]

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-***@public.gmane.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

[David Mertens]

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

Post by s***@public.gmane.org
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
##########################
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.
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
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 Persico]

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

Post by David Mertens
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

Post by s***@public.gmane.org
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
##########################
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.
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
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