Skip to content

Add preamble option to Plugin::MakeMaker #7

wants to merge 1 commit into from

5 participants

gbarr commented Sep 20, 2010

Ricardo, with this small addition it is much easier to do external checks and abort the building of the Makefile in such a way that is friendly to CPAN Testers and prevent false FAIL reports when a dependency exists that is not a CPAN module

@gbarr gbarr Add preamble option to Plugin::MakeMaker
preamble = use inc::MakeMaker;

will allow authors to have code run before EUMM is called.
This is useful if some external dependency check is needed
to prevent CPAN Testers from reporting a fail when it should
report unknown
rjbs commented Oct 15, 2010

I'm looking at writing a better way to do things like this, and I'd rather not commit to this commit just yet, but I may merge it soon, if I can't get to the other thing I'm thinking about.

In the meantime, Makemaker::Awesome might help.

gbarr commented Oct 15, 2010

as Makemaker::Awesome is 100% compatible with Makemaker plugin perhaps you should consider replacing it.

they seem to have taken the approach of making everything overridable by subclassing. Again I was not aware of the [=inc::MyDistMakeMaker / MyDistMakeMaker], where is that syntax documented ?

Also at you have a section [-Transformer] does the leading - mean anything ?

rjbs commented Oct 15, 2010

Awesome's design is not the design I want to make core. I hope to get to that soon. In the meantime, it will continue to work!

I don't know where the = thing is documented. Somewhere, I hope. Consult expand_package_name

The - means "Look under Pod::Weaver::Plugin:: and not Pod::Weaver::Section::"


Hey, I was going to submit something very like this. I have to insert a check at the beginning of Makefile.PL in order to abort an installation in a way that don't produce false-negatives in CPANTesters. This seems to be a very common situation. And I don't want to go overboard using something like Dist::Zilla::Plugin::MakeMaker::Custom, because I don't want to redefine all of Makefile.PL.

The approach taken on this pull request seems reasonable to me. Another one would be to avoid another config and just check for the existance of a file called "Makemaker.preamble" or some such. If it exists it could be included at the beginning of the generated (Makefile|Build).PL.


Is this issue still stalled? What needs to be done for it to become unstalled?

vovkasm commented Jul 23, 2014

I also vote for continue to work on this! I’am as a XS-writer not satisfied with this plugin, also with ::Awesome, so I will go and write my own prototype, but I think right place to this plugin – core Dist::Zilla module.
Basically I want to:

  • Stable Makefile.PL template that support all Dist::Zilla things, so in core
  • Insert code that evaluate some MakeMaker arguments (it very useful for any XS module that need to modify CCFLAGS and LIBS arguments)
  • Insert code to end of template (yes now this easy possible with ::Awesome module)

’am as a XS-writer not satisfied with this plugin, also with ::Awesome

::Awesome is still very much in development, although it has stalled in the last few months due to pressing real-life issues. I do plan on getting back to it soon, but if you can outline some usecases into its issue queue that would be very helpful.


In particular, I am planning on making it easier in ::Awesome to add extra arguments to WriteMakefile().

vovkasm commented Jul 24, 2014

Okey, okey )) I add pull request avar/dist-zilla-plugin-makemaker-awesome#5
This patch closes my second objection. But I continue to think that Makefile.PL template should live in core Dist::Zilla repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.