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. For Inline, you could add a parameter like INLINE_FILES to WriteInlineMakefile() to be explicit about which ones are supposed to contain Inline portions. > It's all a little too DWIMmy for my tastes. Inline allows you not to > think too hard about details. But in the case of CPAN distribution, I'd > like the authors to have at least a baseline level of clue. Yeah, or to put it another way, they should say explicitly what they intend to do. -Ken
