No, its not about make.

schwern on 2009-07-15T21:45:53

In another edition of "I cut and paste from my email", I was responding to a user who doesn't understand what the problem is with using Makefiles to generate Perl modules.

Well, he asked...

-----------------------------

> I could never follow the arguments against Makefiles or Makefile generators.

Fortunately I wrote a talk alllll about it called MakeMaker Is DOOMED!

The make dependency is only part of the problem. There's a small mountain of compatibility issues (which make dialect? which shell? what tools are available? are they GNU or BSD or some broken 3rd party thing? did you know that according to POSIX "cp -r" is deprecated?! or that it considers tar a legacy tool and we should all use something called pax?) in which you wind up rewriting a lot of things in Perl anyway... painfully squeezed through a shell one-liner like dough through a pasta maker.

A shell that often can only safely handle 1024 characters (some versions of Windows, old Unixen, VMS only gives us 255)... oh, and you don't really know how long that command might wind up being because it contains make variables which can change at runtime so you just sort of have to guess and hope nobody uses too many modules or something.

And god forbid you have a filename with a space or special character in it. Now you need to escape everything... but you don't know how a variable is going to be used. Maybe it'll be used by the shell...

$(CMD) $(VARIABLE)

Maybe it'll already be quoted.

$(PERL) -e 'print $(VARIABLE)'

I'm sorry, I got the wrong quoting. Single quotes don't work on most Windows makes so I have to double quote them.

$(PERL) -e "print $(VARIABLE)"

But double quotes expand variables on Unix, and I don't know what's inside $(VARIABLE). What a conundrum! Now I need to write a portable method to write portable one-liners so I can put portable Perl code in my very unportable Makefile.

And what's the odds a module author is going to consider any of that when they extend MakeMaker?

Even if you wrote your own make-like build tool that solved all the compatibility problems and everyone magically had installed you'd still be up shit creek. You're taking a dynamic situation with lots of state and turning it into a bunch of static one liners with no state. Its like writing down the instructions about how to build a custom tailored car for an idiot child to do. You wind up saying "fuck it, we're not even going to try doing that".

See this recent perfectly sensible ticket I had to reject for a concrete example of something which should be easy but is almost impossible in MakeMaker.

Finally, to customize how their modules are built you're asking Perl programmers to write make (through the funhouse mirror of MakeMaker), something they're totally unfamiliar with. The days of Perl programmers being old C programmers is long gone. Any alternative build system has the same problem except NOBODY will know it. Perl programmers know how to write Perl.

Aren't you glad you asked?

There is one thing MakeMaker has over Module::Build. You can skim the Makefile to figure out what its going to do (except for all the logic that went into generating the Makefile in the first place). This makes it more visible to those who know make, for everyone else its just more magical gibberish. Module::Build is more visible to those who know Perl and know to look in Module::Build::Base. It would be nice of MB had an equivalent to "make -d" to report what's going on, what actions are being called and what dependencies are being resolved.


-d flag

dagolden on 2009-07-15T21:55:35

Could you please put a wishlist ticket in the M::B queue -- that shouldn't be hard to add in the dispatch code.

Thanks.

-- dagolden

Re:-d flag

schwern on 2009-07-16T03:04:17

Done. https://rt.cpan.org/Ticket/Display.html?id=47933

Re:-d flag

dagolden on 2009-07-16T12:18:36

Patched. "--debug" has been added to the repository and will be in the next version of Module::Build. At the moment, it will only trace the action flow, but the scaffolding is there for people to submit patches for more diagnostics of interest.

$ Build --debug
Starting ACTION_build
Starting ACTION_code
Copying lib/Module/Build.pm -> blib/lib/Module/Build.pm
Starting ACTION_config_data
Finished ACTION_config_data
Finished ACTION_code
Starting ACTION_docs
Starting ACTION_manpages
Manifying blib/lib/Module/Build.pm -> blib/libdoc/Module::Build.3
Finished ACTION_manpages
Starting ACTION_html
Finished ACTION_html
Finished ACTION_docs
Finished ACTION_build

-- dagolden

Ooops, schwern.org expired?

RMGir on 2009-12-04T16:19:53

I went to read the presentation at
http://schwern.org/talks/MakeMaker_Is_DOOMED/

but the result tells me that schwern.org might be for sale.

Another domain registrar that didn't notify an owner of a domain expiration? :(

Re:Ooops, schwern.org expired?

schwern on 2009-12-04T23:32:47

Another owner who didn't listen to their domain registrar. schwern.dreamhosters.com should be up shortly and mirror schwern.org.