Re^2: Programming Department

[BrowserUk]

Conversely, if you have no intentions of releasing your code to CPAN, you may decide to avoid the nightmare of the unnecessary, undocumented, unarchitected, unfathomable, unmaintainable, over-elaborate, rotting festering mess that is ExeUtils::MakeMaker completely.

And for anything you do have a hankering to release to CPAN, spend an hour or two trying to understand what the hell is going on when you run the Makefile.pl for any moderately complex CPAN module, and try to imagine the trouble you are going to have to incorporate any extra customs steps.

For example, say you would rather have your build process extract the files directly from your source code repository? Rather than having to do this as an extra manual step, with the inherent weakness of forcing the duplication of your source tree and/or imposing the convoluted pattern that is the 'blib' phenomena upon your source tree structure. Look hard and think very carefully how you would modify EU::MM to do this?

Of course, I (infamously) do not have any CPAN modules to my credit, so I may be just crying wolf, so I urge you to look at and think about the problems this route would cause you. Also, take a look around at some of the comments made about the ExtUtils::MakeMaker module by it's current maintainer.

And if the Module::Build route looks interesting, have a good look around at the internecine struggle between it's proponents and the EU::MM diehards.

[Aristotle]

I find the typical Module::Build opponent’s argument that it’s not mature and won’t be for a long time to be quite disingenious. Only software which has users improves. The argument that you inflict pain on users is understandable, but for simple needs you can avoid that by way of create_makefile_pl => 'traditional'. And while users complain that there is no compatible PREFIX support, I always found it a mess to deal with as a user and applaud the coming of install_base.

The other option is Module::Install, which for some reason I can’t bring myself to like, even though everyone using it seems to rave about it. Last I looked, I couldn’t find much documentation, anyway.

[adamk]

Try clicking on the link to Module::Install you just created... there's been a total overhaul of the documentation in the last few weeks. (still more to go, spelling and grammar etc)

Proper SYNOPSIS, a list of the commands, cookbook stuff... is there anything you feel is still missing?

[adamk]

Yes, you're crying wolf.

Forget EU::MM and Module::Build and just use Module::Install, which wraps BOTH of them as needed and makes writing installers almost trivial.

http://search.cpan.org/src/ADAMK/PPI-1.109/Makefile.PL

You example is bizarre... you only need to store the actual modules, the blib stuff (which is used for compiling and so on) only exists between when you run Makefile.PL and when you run make install. It never goes anywhere near the repository

As for doing things from the repository, we just use...


svn checkout http://..../project
cd project
perl Makefile.PL
make
make test
make install

[BrowserUk]

and makes writing installers almost trivial.

And why on earth would the OP want to "write installers" for internal code development? Please go back to the top of the thread and read the context in which my post was made.

[pileofrogs]

I write installers for my internal stuff. It helps me keep things uniform and I never have to wonder how a particular do-dad was installed. I can read the installer if I'm curious. My life got so much better when I started doing that.

-Pileofrogs

Update: A lot of folks are arguing about installers vs. no installers like there's only one way to do it. The important thing isn't that you use a whiz-bang installer technique, or even that you use the same technique on all your stuff. The important thing is making your stuff with a reasonable installer.

For example, I might build a perl module with one of the made-for-CPAN tools, or I might use make to run a spell checker on my HTML web pages... Either way, I know when my stuff is up to date.

[Aristotle]

Because presumably, he’s not so terminally insane as to conduct his development on a production machine. And as soon as any sort of deployment is required, things get massively easier if you wrap your stuff up such that you can ship a package installable on a virgin machine using standard incantations. Just like pileofrogs says, I’ve found it made my life a whole lot easier, regardless of whether the code is actually ever going to live on any more than three machines.

Setting up the skeleton to allow for this before you start working on any code is so simple, there’s really no excuse not to do it. (If you haven’t developed any particular tastes and need some skeleton to grow from, things like Module::Starter::PBP will take care of you.)

[ides]

My intent wasn't to promote ExtUtils::MakeMaker, I too have found it hard to work with for complex tasks, which is why I now use Module::Build and am going to be taking a hard look at Module::Install in the near future.

I also think you misunderstood most of my post. There is no duplication of your source tree, and no blib weirdness. Your source repository for a particular app *IS* your build environment. There is no need to have your build process checkout the source, your simply build a dist in your working copy.

To give a detailed example let's say I have a mod_perl application that I'm building called 'Foo'. I start off my application with module-starter and it creates the Foo/ tree for me with a lib/ ( where your code goes ) and the other various elements we're all accustomed to.

Once I've put in stubs for all of my various modules, Foo::Main, Foo::Admin::*, Foo::Model, etc... I then check this entire structure into my revision control system ( I use subversion ) and I'm done.

No blib weirdness ( incidentally this directory is only created when actually install your app ), no duplication of my source tree, no convoluted patters I can think of... unless of course you prefer to just drop everything in some very large directory without any organization.