Re^2: Unwritten Perl Books

[Solo]

It's been awhile since I skimmed it, but I thought 'Embedding and Extending Perl' was basically XS in a Nutshell.

[doom]

On subjects like this, I often turn to Writing Perl Modules for CPAN by Sam Tregar, from the Apress. It talks about the h2xs structure, and ways of doing automated testing and so on... Here's a Simon Cozens review (he's a bit more down on the book than I am).

That doesn't answer the whole question though... very few professional software development environments would be based on the CPAN packaging system (it could probably be done, but would seem like a kludge). The ways people really do it would be interesting to hear about (just as an example: is there any standard at all outside of the h2xs world about where to put test files and what to name them? Myself, I lean toward putting the test for Modular::Stuff in a directory named "t" located in the same place as the Stuff.pm file, and calling it Modular-Stuff.t, but other choices are possible).

There's nothing wrong with Randal Schwartz "Learning Perl Objects" (I bought a copy to read on vacation once.) It could easily be that going through that book would be a step in the direction of learning how to do large scale programming, but it's a pretty early step.

[adrianh]

very few professional software development environments would be based on the CPAN packaging system (it could probably be done, but would seem like a kludge

I'm curious why you think the CPAN packaging system would seem like a kludge. I've always used EU:MM (or more recently Module::Build) for my commercial work with great success. Why would I bother reinventing the wheel?

The ways people really do it would be interesting to hear about (just as an example: is there any standard at all outside of the h2xs world about where to put test files and what to name them?

I often find myself with a hierarchy of test classes that I put in t/lib that mirrors the files in lib/.

[doom]

adrianh wrote:

doom wrote:

very few professional software development environments would be based on the CPAN packaging system (it could probably be done, but would seem like a kludge

I'm curious why you think the CPAN packaging system would seem like a kludge. I've always used EU:MM (or more recently Module::Build) for my commercial work with great success. Why would I bother reinventing the wheel?

At a guess we're thinking about slightly different situations. I'm envisioning something like a commercial website, with a number of developers working simultaneously on several hundred modules, but with out any need to package them up and ship them to someone else.

In this kind of situation, you're not going to run "h2xs" for every module that you write. If you're developing inside a structure like this:

  ~/dev/Modular-Stuff/
         Changes
         MANIFEST
         Makefile.PL
         Makefile
         README
         lib/
           Modular/
             Stuff.pm
         t/
            Modular-Stuff.t

It just seems like there are too many annoyances in the way. Do you have to do a "make install" to test this module in context? Or maybe you need to add ~/dev/Modular-Stuff/lib/ to the front of your PERL5LIB so that the development version of the module is seen by perl? And what do you check-in to version control, ~/dev/Modular-Stuff/lib/Modular/Stuff.pm, or the installed version? The developer would probably want to check-in the development location along with the t/*.t files, but the site maintainers would probably prefer the installed version be checked in for branching/tagging purposes. I suppose you could try checking in both, but that sounds pretty scary.

The ways people really do it would be interesting to hear about (just as an example: is there any standard at all outside of the h2xs world about where to put test files and what to name them?

I often find myself with a hierarchy of test classes that I put in t/lib that mirrors the files in lib/. Funny, I never like the idea of mirroring trees like that. It seems inelegant to me to have to create a chaing of several directories when you already have them right next door.

But then it's not like I can't use structures like this if someone else makes that design decision (e.g. Mason works that way). It's probably just a personal preference on my part.