in reply to Re^6: Programming Department
in thread Programming Department

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?