It was just pointed out to me that MakeMaker after 6.17 has broken the
building of the Swig/Perl bindings for SVN.  If you recall 6.18 was when
the system for creating the blib directories was redesigned to eliminate
the .exists files.  It turns out the redesign is flawed and I was a bit
rash to throw out the old system without fully understand it.  The problem
with SVN has illustrated what was wrong.

So I figure I'll spell out the blibdirs architecture and what its going to
change to.  Hopefully folks that know make better than I do will vet it for
sanity.


Backstory.  Here's a simplified version of how MakeMaker used to
create blib directories in 6.17 and back.

# Assume this is the Makefile for Some::Module
INST_LIB = blib/lib
INST_LIBDIR = $(INST_LIB)/Some

$(INST_LIBDIR)/.exists :: /path/to/your/CORE/perl.h
        $(MKPATH) $(INST_LIBDIR)
        $(TOUCH) $@
        $(EQUALIZE_TIMESTAMP) /path/to/your/CORE/perl.h $@

...and so on for all the INST_*DIRs that make up the stuff in blib/.
Here's the important things about this sytem.

1)  Each directory has its own target.
2)  The targets do not refer to the directories directly but rather to
    a dot file in that directory.
3)  You can override an INST_* macro and change the location of your
    blib dirs.  For example, the perl core does this to build itself.

I'm still not quite sure what the point of setting .exists to the same
mtime as perl.h was instead of just touching the file.  And this is
what prompted the change.  OS X didn't ship perl.h and suddenly
pure-perl modules wouldn't install.

Here's what it was changed to in 6.18.

INST_LIB = blib/lib
INST_LIBDIR = $(INST_LIB)/Some
...and so on for the INST macros...

blibdirs.ts :
        $(MKPATH) $(INST_LIBDIR) $(INST_ARCHLIB) $(INST_AUTODIR) \
          ...and so on for all the INST macros...
        $(TOUCH) $@

No more perl.h.  And I figured, why spread it all out?  Do it all in one 
shot, touch one file to indicate the deed is done.  No .exists files.  No 
complicated code to generate them.  Make all the directories and touch a
file to indicate you're done.

But you'll notice that each directory no longer has its own target.
I figured this wouldn't be a problem, they've all been created.  Right?

Wrong.

The SVN Swig/Perl Makefile.PL generates a Makefile for each individual
module *all in the same directory*.  I'm not even going to ask why or if 
its a good idea, its more important that it illustrates a design flaw in
MakeMaker.

Each module is built one after the other.  The first Makefile is for 
SVN::Core.  It generates its blib directories, creates the blibdirs.ts 
stamp and does its thing.  Then the next Makefile (Makefile.client) is
run.  It sees that blibdirs.ts is there and doesn't bother to make its
blib directories.  Some of them are different from SVN::Core.  Whoops.
Directories don't exist and things go boom.


Here's a simplier illustration of the problem.

[~/devel/CPAN/ExtUtils-MakeMaker] perl Makefile.PL
...blah blah write the Makefile...
[~/devel/CPAN/ExtUtils-MakeMaker] make
...make blib, copy stuff into it, manify...
[~/devel/CPAN/ExtUtils-MakeMaker] rm -rf blib
[~/devel/CPAN/ExtUtils-MakeMaker] make
cp bin/instmodsh blib/script/instmodsh
cp: cannot create regular file `blib/script/instmodsh': No such file or 
directory
make: *** [blib/script/instmodsh] Error 1


It really should be more robust than that.

Coming up next, the new design!  VMS users, hang tight.  You come in next
part.


-- 
Michael G Schwern        [EMAIL PROTECTED]  http://www.pobox.com/~schwern/
But I wore the juice!

Reply via email to