David, Wow, I don't think I could have possibly misread your previous email any worse. I didn't understand most of what you were saying so I googled your name, found M::B::PDL, said "oh, he's already done it!" and figured that was that. However, most of what I wrote yesterday for M::B::PDL was still usable even with straight M::B.
Anyways, I reread that email and in addition to adding the ExtUtils::ParseXS 3.0 req, I tried to write something that would rename .pd files to .pm.PL files and add the ~25 line header you illustrated. Apparently, such file munging operations are recognized and supported by Dzilla through the Dist::Zilla::Role::FileMunger role. Thus, the idea of "put .pd's in lib/ and the plugin will do the rest" part is untouched. Note I should probably be encapsulating the header and inserting a function call instead... Relevant lines are 99-155 here: https://github.com/tnishimura/Dist-Zilla-Plugin-PDLPP/blob/f741dc36e37665eb2ff06cb58a53f880cf88a176/lib/Dist/Zilla/Plugin/PDLPP.pm#L99 The improper handling of .pd's in this case should not matter for DZilla b/c in the distribution uploaded to cpan, all the pd's will have been converted to pm.PL and thus properly handled like in PDL::Drawing::Prima. Assuming this all ends up working, is there any disadvantage to using M::B instead of EUMM, besides the thing about all the compiler and linker flags having to be the same? Thank you for the thorough explanations, Tom On Fri, Aug 24, 2012, at 08:03 PM, David Mertens wrote: > On Fri, Aug 24, 2012 at 7:09 PM, Tom Nishimura <[email protected]> wrote: > > Well that made it a little too easy! The reason I was asking was b/c I > > was trying to write a Dist::Zilla plugin: > > > > https://github.com/tnishimura/Dist-Zilla-Plugin-PDLPP > > > > (still pre-alpha quality). > > Very nice! I don't use Dist-Zilla, but isn't that M::B based? So I > gave you almost everything you needed to stick with M::B and not > branch out to EU::MM, though it looks like you had that under control, > too. I know that Joel has worked a little with Dist::Zilla and may > have some insight if you run into trouble there. > > > I'll have to study the code of Module::Build::PDL when I have time. > > I recommend against Module::Build::PDL. I hacked that module together > years ago before I realized that a .pd is just a .pm.PL that gets > invoked by PDL's EU::MM black magic with a proper incantation of > "-MPDL::PP". M::B::PDL added a file type called "pd" that gets > properly invoked with that incantation and properly configures linker > flags and other mumbo jumbo. However, if you rename your .pd file to > .pm.PL, you can put a "use PDL::PP (...)" at the top of your .pm.PL > file and get *identical* results, with plain Module::Build, without > any black magic, using the code that I already pointed out. The only > thing worth noting is that PDL::PP generates both a .pm file and a .xs > file, so that's why I add the .xs file to the current build's > "add_to_cleanup" list in the .pm.PL file. > > I should probably put a deprecation notice in Module::Build::PDL's > main documentation, shouldn't I? :-) > > > I honestly don't understand yet the business of ExtUtils::ParseXS. > > XS is Perl's C extension specification lingo. ExtUtils::ParseXS > converts XS files into pure C files that can be compiled into shared > object files that Perl knows how to dynamically load. The > ExtUtils::ParseXS problems involved BOOT sections (which are C > functions that get called when your module is first "use"d), and in > particular having BOOT sections in multiple XS files. I believe that > all pdlpp files generate BOOT sections, so if you have multiple pdlpp > files in your distribution, you'll need EX::PXS v3 or higher to avoid > these issues. The problem was very strange because it would happen > that certain modules would have the BOOT code from *other* modules, > almost as if the ExtUtils::ParseXS parsing set some global variables > and forgot to clear them before moving to the next XS file. > > > What is a *.pm.PL file? Is it used to dynamically generate PM's? > > Yes. As Joel said, in the Perl build chain, filename.any.PL is assumed > to be a Perl script that is run at build time and is expected to > create filename.any. It is executed with the file's name as the first > command-line argument. There is an extra advantage, though. The reason > that I prefer to use .pm.PL extensions is because CPAN properly > associates the pod documentation for .pm.PL files as "Module" > documentation rather than "Documentation". For an example, search for > FFTW on this page: http://search.cpan.org/~chm/PDL-2.4.11/, and > contrast that with the location of the documentation for both of my > pdlpp files in PDL::Drawing::Prima: > http://search.cpan.org/~dcmertens/PDL-Drawing-Prima-0.07/ > > > > > Tom > > > > I must admit that I didn't look over your original question, which > involved module loading issues when compiled under > ExtUtils::MakeMaker. Have you tried switching over to Module::Build, > and if so, did that work? _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
