Questions

[Chromatic]

Hi all,

I've held off on adding Parrot::Embed to the Parrot repository, pending
satisfactory answers to a few questions. I have ideas, but I'd really love
to get input from any or all of Bernhard, Jerry, Will, Leo, and Chip. This
one's a bit weird, so I want to disrupt life as little as possible.

* Where should the raw Parrot::Embed code go? It's not pure-Perl; it has an
XS component that needs building.

* What's the best way to integrate building this module from the main
Makefile? Should it be part of that process?

* Where should the built module go, and how can we make that work in a
cross-platform way? Copying the two (for now) necessary files out of
blib/lib appropriately is probably the right answer.

* Parrot::Embed uses Module::Build, mostly because I find EU::MM bletcherous
and hateful. Porting it to EU::MM is pretty easy, but I haven't done it
because it needs a custom step before testing to build a PBC file. Leaving
it as it is makes maintaining it a little easier for me, but it makes M::B a
dependency for building Parrot. That may or may not be an issue, depending
on what Bundle::Parrot pulls in.

* All of these questions assume that Parrot::Embed *should* go into the
repository. I think it's cool and useful and it lets us use
Parrot::Test::Embedded, which exercises the embedding interface with more
realistic code and hopefully speeds up and cleans up the test suite somewhat.
That may be insufficient reason, but it's what I have right now.

* Should this be a dual-lived module on the CPAN?

The source hasn't changed much since my last snapshot:

http://wgz.org/chromatic/perl/Parrot-Embed.tar.gz

-- c

[Joshua Hoblitt]

On Mon, Jul 31, 2006 at 10:30:36PM -0700, chromatic wrote:
> * What's the best way to integrate building this module from the main
> Makefile? Should it be part of that process?

That depends. Are any of the standard regression tests going to require
this module?

> * Where should the built module go, and how can we make that work in a
> cross-platform way? Copying the two (for now) necessary files out of
> blib/lib appropriately is probably the right answer.

I'd say let Module::Build handle the install. The install process can
invoke Module::Build if it's to be part of the default install.

> * Parrot::Embed uses Module::Build, mostly because I find EU::MM bletcherous
> and hateful. Porting it to EU::MM is pretty easy, but I haven't done it
> because it needs a custom step before testing to build a PBC file. Leaving
> it as it is makes maintaining it a little easier for me, but it makes M::B a
> dependency for building Parrot. That may or may not be an issue, depending
> on what Bundle::Parrot pulls in.

I'll vote for adding M::B to Bundle::Parrot.

-J

--

[Chromatic]

On Tuesday 01 August 2006 12:24, Joshua Hoblitt wrote:

> On Mon, Jul 31, 2006 at 10:30:36PM -0700, chromatic wrote:

> > * What's the best way to integrate building this module from the main
> > Makefile? Should it be part of that process?

> That depends. Are any of the standard regression tests going to require
> this module?

For now, no. I'd like to have the option of running the standard regression
tests through it, but it's not stable enough yet.

> > * Where should the built module go, and how can we make that work in a
> > cross-platform way? Copying the two (for now) necessary files out of
> > blib/lib appropriately is probably the right answer.
>
> I'd say let Module::Build handle the install. The install process can
> invoke Module::Build if it's to be part of the default install.

How about when just building Parrot but not installing it?

I'd also like to run the Parrot::Embed tests as part of the normal Parrot test
suite.

-- c

[Joshua Hoblitt]

I'm guessing that Parrot::Embed won't be the last M::B module that were
going to stand to ship with Parrot. It would be nice to solve this
issue in a somewhat general way so other packages can more or less be
mechanically included for use. If not for installation, at least for runtime.

While I'd been hoping that M::B had a public method for changing 'blib'
this appears not to be the case (just looking at the pod). If this
functionality were added we could have the root makefile invoke each
module as `perl Build.PL --blib [buildroot/somedir]`, use that path for
runtime testing, and still let M::B handle the packages own
installation. I admit this scheme is a little hackish but it avoids
having to do a custom setup for each bundled package. Thoughts?

-J

--

[Chris Dolan]

On Aug 1, 2006, at 2:45 PM, Joshua Hoblitt wrote:

> While I'd been hoping that M::B had a public method for changing
> 'blib'
> this appears not to be the case (just looking at the pod). If this
> functionality were added we could have the root makefile invoke each
> module as `perl Build.PL --blib [buildroot/somedir]`, use that path
> for
> runtime testing, and still let M::B handle the packages own
> installation. I admit this scheme is a little hackish but it avoids
> having to do a custom setup for each bundled package. Thoughts?

That syntax works:

% perl Build.PL --blib=foobar
Checking whether your kit is complete...
Looks good

Checking prerequisites...
Looks good

Creating new 'Build' script for 'FLV-Info' version '0.11'
% ./Build
lib/FLV/File.pm -> foobar/lib/FLV/File.pm
...
% perl -MModule::Build -le'print Module::Build->VERSION'
0.2801

This also works:

my $mb = Module::Build->new(
...
);
$mb->blib('foobar');
$mb->create_build_script;

Chris

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)

[Joshua Hoblitt]

Well, I guess that's what I get for reading the documentation instead of
the code. ;)

-J

--