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?
|
|---|