h2xs comes with perl by default, so most people who have perl are already going to have h2xs. So your title isn't quite right (I know, pick, pick, pick).

Anyway, h2xs is useful for building general modules, but it has a lot of stuff that is useful only for XS modules that you'll have to remove for PP modules. A better solution for PP is ExtUtils::ModuleMaker (reviewed here on PM).

I used to use ExtUtils::ModuleMaker for all my modules, but now I find it's too much trouble. The basic code, README, and POD it creates isn't like my current style for writing modules, so I end up deleting a lot of the stuff it created. In the time it takes for me to delete it, I could have made the directory structure myself and written in my own basic code.

h2xs comes with perl by default, so most people who have perl are already going to have h2xs. So your title isn't quite right (I know, pick, pick, pick).

Yeah -- I should have said something like "A tool you've gotta try". I knew that h2xs was part of the Perl distribution.

Anyway, h2xs is useful for building general modules, but it has a lot of stuff that is useful only for XS modules that you'll have to remove for PP modules.

Right -- I figured that from the 'xs' at the end, even though it sounds like Ingy's Inline::C is the preferred method when linking C code into a Perl script/.

I just know that watching my colleague build all this stuff, everything was pre-cooked and ready to go. Thanks for the link to ExtUtils::ModuleMaker, I'll definitely check that out.

Alex / talexb / Toronto

Life is short: get busy!

Right -- I figured that from the 'xs' at the end, even though it sounds like Ingy's Inline::C is the preferred method when linking C code into a Perl script/.

This is probably subject to another meditation of some sort, but the way I see it, Inline::C is great, I love it, but it's not suited for distributions into environments where there is not a compiler present -- or for Windows environments either. Thus I doubt it can be the preferred method for production code. Unfortunately, I have yet to learn XS, but I get the feeling around here that Inline::C is considered 'training wheels' -- please correct me if I've gotten that wrong. After all, XS modules have to be compiled as well, but perhaps it is easier to distribute them in native form? Are there sufficient performance tradeoffs (not bugs, per se, but performance tradeoffs) when using Inline::C rather than XS after initial compile/build time?

Anyway, h2xs is useful for building general modules, but it has a lot of stuff that is useful only for XS modules that you'll have to remove for PP modules. A better solution for PP is ExtUtils::ModuleMaker (reviewed here on PM).

FYI: h2xs has an -X option to omit the XS portion. I normally create pure-perl modules with h2xs -XA -n <module-name>, as advised in the Perl Cookbook (recipe 12.8)

I second the review. I've found the script on that node to be extra handy. I've used it to auto-generate the directory structure for every distribution we use internally.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Even after reading the thread you cite, i still think the statement "it makes broken file layouts" is missleading.

It doesn't make the exact directory structure that you will ultimately have once the module is installed, it makes *a* directory structure designed to let you easily group all files related to the distribution "Foo::Bar" in one directory in your "development" directory, and files related to "Foo" in a seperate directory under your development directory -- so they don't get bundled together by mistake.

The generated Makefile.pl should "Do the Right Thing" and find your module when it comes time to install it.

You can allways install it into "./test_lib" to confirm that the installed directory structure is correct, and that the module works.

Michael Schwern, maintainer of ExtUtils::MakeMaker, also called it broken and said he wanted to fix it at some point. It makes a layout which is practical only if you are doing an XS module with an actual compile step. For pure perl modules, it is very annoying to develop within. Either you have to keep installing it every time you edit the file, or you mess with @INC and edit it within the blib/ directory (where it goes when you do the make) and then copy it back into place when you finish. It's even worse if you have multiple modules in your distribution with different namespaces (i.e. Foo::Something and Bar::Something). I have seen people other than me get extremely confused by the h2xs structure. Basically, I can't see a good reason to use when ExtUtils::ModuleMaker exists.

Abigail