On 06/10/02 21:16 +1000, Ken Williams wrote:
>
> On Sunday, October 6, 2002, at 05:34 PM, Brian Ingerson wrote:
>
> > On 06/10/02 14:35 +1000, Ken Williams wrote:
> >>
> >> On Saturday, October 5, 2002, at 02:50 PM, Brian Ingerson wrote:
> >>> There are a few rules when making Inline modules:
> >>>
> >>> - One Inline block per module.
> >>> - NAME must be the same as the module package.
> >>> - If you really want two objects you must put them in separate
> >>> modules with separate packages. Don't try to get tricky here and
> >>> use a second module with the same package name. That won't work.
> >>> - To bundle two or more Inline-based modules in the same CPAN
> >>> distribution each one must have its own Makefile.PL. This means
> >>> you must use subdirectories. Don't worry, it's easy. And it
> >>> works great.
> >>
> >> I'll chime in here with my usual wish that the subdirectories &
> >> separate Makefile.PLs not be necessary in this case. Just to
> >> keep it on your radar screen. ;-)
> >
> > It is definitely on my radar. But it's not so easy to figure out exactly
> > how this would work. I suppose I put Inline make rules in the Makefile
> > for each additional module in the lib tree. But how do I know which
> > modules are pure Perl, and which ones are extension modules?
>
> Yeah, that's the tough part. Module::Build currently lets you put .xs
> files directly in lib/ and it just processes them in-place by calling
> the proper xsubpp/C commands directly. But it has the .xs extension to
> tell it what to do.
Hmm. So is the directory layout:
./lib/Foo/Bar.pm
./lib/Foo/Bar.xs
./lib/Foo/Baz.pm
./lib/Foo/Baz.xs
??? I suppose that's all well and good. One problem is, what does this mean:
./lib/Foo/Changes
./lib/Foo/README
./lib/Foo/t/
I guess you could assume that these apply to both Foo::Bar and Foo::Baz. If
you wanted them to just apply to Foo::Baz, then you put them in:
./lib/Foo/Baz/Changes
./lib/Foo/Baz/README
./lib/Foo/Baz/t/
But what if there was also:
./lib/Foo.pm
I'd like to know how Module::Build reacts in this regard. One reason is that
I recently suggested on P5P the these files get installed into the Perl
library tree (along with the .pm-s and .so-s). Crazy? Well in 5.8 it already
has happened, although I surmise by mistake. Look at Switch.pm.
> find /usr/local/perl580/lib/5.8.0 | grep Switch
/usr/local/perl580/lib/5.8.0/CGI/Switch.pm
/usr/local/perl580/lib/5.8.0/Switch
/usr/local/perl580/lib/5.8.0/Switch/Changes
/usr/local/perl580/lib/5.8.0/Switch/README
/usr/local/perl580/lib/5.8.0/Switch.pm
If all modules installed these files, we could write the tools:
- perltest
- perlreadme
- perldelta
I also suggested that Changes files be done in YAML. We'll see...
>
> For Inline, you could add a parameter like INLINE_FILES to
> WriteInlineMakefile() to be explicit about which ones are supposed to
> contain Inline portions.
Yeah, that could work. Or they could create an empty file:
./lib/Foo/Bar.pm
./lib/Foo/Bar.inl
./lib/Foo/Baz.pm
Only Foo::Bar has Inline. I'd end up generating a file like this anyway.
It's like pm_to_blib. I use it as a make dependency. Otherwise the
Inline stuff would compile everytime you do a make, which sucks when you
are developing inside this directory.
If I went this route, I'd want Inline::MakeMaker::WriteMakefile to
'touch' the Bar.pm file to force the compile after a 'perl Makefile.PL'.
I think this approach is reasonable.
Cheers, Brian
