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.

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.)

Makeshifts last the longest.

there’s really no excuse not to do it.

I don't need an excuse, I have plenty of reasons.

• It is not (only) using EU::MM that is the problem, it is what it produces once you get the incantations correct.

  The makefiles it produces are unintelligible(* see below for an example).

  I have no idea how to add extra C compiler switches (disable certain warnings /wd<n> or to produce assembler files /Fa<file> or... ) to this mess.

• I have projects that use compilers other than a C compiler...how do you integrate those into this mess?
• The same goes for any number of other tools that I use whilst developing and testing that simply do not fit into the EU::MM/M::B/other way of operation. Documentation tools; graphics file conversion tools, etc., etc.
• The directory structure imposed by these tools does not accommodate me. Storing source files in a directory called ./lib?

  For the OP, if his shop is producing web sites for customers, he probably has in-house common elements used as a part of multiple customers projects. He may have multiple projects per customer. There are likely common code elements across customer projects.

  Trying to force fit all these into the directory structures required by these build tools is insanity.

  And having to copy files from whatever directory structure is appropriate for his development process, to a completely different structure in order to accommodate a packager--for most pure perl projects nothing more that a glorified file copying routine that could in many cases be done (easily and cleanly and understandably) by 5 or ten lines of batch file--make no sense either.

  Meta question. Can anyone explain to me why the source files start in one place, get copied to another place before being finally copied to where they should have been put in the first place?

If for you, project equals a perl module, then it may make some sense, but otherwise, none at all.

And from what I have seen of the alternatives to EU::MM, be it M::B, or M::I and others, they simply add extra layers on top of the underlying problems. You simply end up with the same unintelligible mess of a make file, but you are now an extra layer (or two) removed from how it is produced. The inputs may be simpler (looking), and if what they produce does all you need it to do, then that's great. But if it doesn't, if you need to modify it, or add to it, your even worse off than with EU::MM. You now have to plunder your way through an extra layer of documentation, and an extra layer of metafiles, boiler-plate include files, and heavily nested "OO" layers trying to work out where you need to make what change in order to affect the makefile that gets produced.

If that is your idea of heaven, good luck to you.

Read more... (33 kB)

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

It is not (only) using EU::MM that is the problem, it is what it produces once you get the incantations correct. The makefiles it produces are unintelligible(* see below for an example).

I agree. Which is why I use Module::Build and avoid all that tedious mucking about with make files completely.

I have projects that use compilers other than a C compiler...how do you integrate those into this mess?

With M::B I just write new dependencies, actions, etc. in a nice subclass.

The directory structure imposed by these tools does not accommodate me. Storing source files in a directory called ./lib?

For perl files this doesn't bother me at all personally. However, if it did, I'd just tweak M::B so it looked somewhere else. For non Perl files I can stick them in whatever directories I like and tweak M::B appropriately.

Trying to force fit all these into the directory structures required by these build tools is insanity.

With EU::MM it can be a pain I agree. With M::B I've found it quite pleasant.

And from what I have seen of the alternatives to EU::MM, be it M::B, or M::I and others, they simply add extra layers on top of the underlying problems. You simply end up with the same unintelligible mess of a make file, but you are now an extra layer (or two) removed from how it is produced.

For M::B at least this is untrue. There is no Makefile. The installation process is handled by a pure perl program that is very tweakable.

---

I'm curious - what do you use for your automated build/install processes?

Meta question. Can anyone explain to me why the source files start in one place, get copied to another place before being finally copied to where they should have been put in the first place?


Well, basically you start with source files in lib.

The make process "compiles" these into blib/lib (platform neutral) and blib/arch (architecture-specific).

In ordinary pure-Perl modules this can look a little odd. For modules with C-code or that uses File::ShareDir and other things, the blib/lib and blib/arch file carry some significance.

Specifically, when make test runs, the tests are run against the "compiled" modules and not against the original source files.

Things like autosplit/etc also make use of these techniques.

Then when you install the built files in blib are copied to the relevant places in the underlying system.