On Monday, October 7, 2002, at 12:12 AM, Brian Ingerson wrote:
> On 06/10/02 21:16 +1000, Ken Williams wrote: >> 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 don't know - what does that have to do with it, though? Extra files in lib/ shouldn't affect the building of XS/Inline files. > I'd like to know how Module::Build reacts in this regard. It will only install .pm files and any derivatives of .xs files. Extra junk in lib/ (for instance, .cvsignore files) won't be installed. >> >> 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 Apparently empty files don't expand well on some systems. I've had complaints about this in a distribution of mine before. > 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. Why couldn't the files just depend on the actual files they depend on? Why is a dummy necessary? > > 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'. You could just make the Bar.xs or other derivatives depend on the Makefile. -Ken
