5

I'm working on a Perl module called Mite. It is a "compiler", of sorts. You write Perl classes using a Moose-like declarative OO syntax. Rather than doing all the work to put the class together every time it's executed, Mite does that work at build time. It generates an extra file containing the Perl code for your accessors and inheritance and whatnot.

This extra file is put into lib with the rest of your code and released with your project. As a result, the installing user does not need to install Mite and the code loads faster.

During development, the mite compiler is run when make or Build is run. So things like make test and ./Build test just work. This is accomplished by using special shims for MakeMaker or Module::Build.

This works fine for Module::Build, but ExtUtils::MakeMaker does not see the mite files. MakeMaker hard codes a list of what is in lib when Makefile.PL is run. The pm_to_lib step then fails to copy the generated files into blib where make test will see them.

How can I best work around this problem? I wish the process to remain transparent to the developer (once they've loaded the appropriate shim), and require no special dependencies for the installing user.

UPDATE: Here is a clearer example. Let's say you have a project like this.

Makefile.PL
lib/
    Foo.pm
    Bar.pm
    Foo/
        Thing.pm
t/
    foo.t
    bar.t

You run perl Makefile.PL and then make. The make step has been modified to generate an extra .mite.pm file for each .pm file. After the make step, what I want is this.

Makefile.PL
Makefile
lib/
    Foo.pm
    Foo.pm.mite.pm
    Bar.pm
    Bar.pm.mite.pm
    Foo/
        Thing.pm
        Thing.pm.mite.pm
blib/
    lib/
        Foo.pm
        Foo.pm.mite.pm
        Bar.pm
        Bar.pm.mite.pm
        Foo/
            Thing.pm
        Thing.pm.mite.pm
t/
    foo.t
    bar.t

All the new files introduced into lib have been copied into blib/lib where they can be seen as part of make test. What I get instead is this.

Makefile.PL
Makefile
lib/
    Foo.pm
    Foo.pm.mite.pm
    Bar.pm
    Bar.pm.mite.pm
    Foo/
        Thing.pm
        Thing.pm.mite.pm
blib/
    lib/
        Foo.pm
        Bar.pm
        Foo/
            Thing.pm
t/
    foo.t
    bar.t

That is because the Makefile is generated by Makefile.PL with a hard coded list of what is in lib.

(This is particularly silly, I maintained MakeMaker for 10 years and failed to fix this.)

Schwern
  • 153,029
  • 25
  • 195
  • 336
  • 1
    I'd suggest taking the Dist::Zilla approach and ditching the use of EUMM/MB in the development environment: just use them for installation on the end-user's machine. To do your pre-processing and build the tarball use a different tool (which may or may not be a configuration of Dist::Zilla). – tobyink May 28 '14 at 21:13
  • @tobyink I do not wish to restrict a project that wishes to use Mite to a particular installation tool. I also do not wish to introduced a whole new development process. It has to integrate cleanly with their existing build step. – Schwern May 28 '14 at 22:42
  • Dist::Zilla ***would*** integrate cleanly with our existing build steps ;-) Mite sounds like a great idea Schwern, looking forward to seeing where it ends up! – Kaoru Jun 05 '14 at 19:27

1 Answers1

1

I wound up adding a new target and having pm_to_blib depend on it. The new target just moves all .pm files from lib/ to blib/lib/. The redundancy shouldn't matter.

I'm not happy with this solution, but it appears to work.

https://github.com/evalEmpire/Mite/commit/feff24e4d68e062a06a721591ff0d785c5dad80b

Schwern
  • 153,029
  • 25
  • 195
  • 336