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? David -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
