Re: Find .pm files automatically (was Re: Fix git-svn tests for SVN 1.7.5.)

On 2012.7.17 5:01 PM, Jonathan Nieder wrote:

quoted

It also moves Error.pm into a bundle directory.  This both makes it just
another directory to scan (or not scan), but it also makes it possible to
bundle additional modules in the future.  ExtUtils::MakeMaker uses this
technique itself.

This is not so much "also" as "as an example to demonstrate the
technique", no?  I guess I'd prefer it to be in a separate patch, but
this way's fine, too.

I wrote the MakeMaker system so I was just cribbing off that.  It made more
sense to build a list of directories to scan and then scan them than to add
individual file exceptions later.  I could put it in a separate patch, but it
would require some bending.

You'll probably hate this.  Because we have a bunch of patches to
incorporate, I think it's worth spending the time to make that go as
smoothly as possible for later patches.

Sorry.  I have lots of experience with git but very little with the email
submission tools.  I've always either just done everything via repositories or
used Github.

It sounds like I should figure out the git-send-email tool and do this very
slowly.

The word "bundles/" left me a little nervous, because I (ignorantly)
imagined that this might be some specialized facility like Python eggs
or Ruby gems.

Nope, just copy .pm files in.

Is the intent that this directory contains CPAN modules
we want to be able to depend on?

Yes.

Is there really any intention of having more of them than Error.pm?

No idea, this is my first look at the code, but now it's possible.  In my
experience, if there's a barrier to using CPAN modules then people won't use
them.  They'll rewrite the functionality poorly.

Before this patch, in the default case (with MakeMaker), "make
install" wrote a manpage in <mandir>/man3/private-Error.3pm.  Does it
still do so after the patch?  Will people who have installation
scripts that expected that manpage have to change them, and if so, is
the new behavior better to make up for that effort?

The man page is now man3/bundles::Error::Error.3 which is equally as incorrect
as man3/private-Error.3.  It is possible to correct that so it's man3/Error.3,
but that's going to require some effort.  Basically its in the same boat as
PM.  Once you have to change one you have to change them all.

Why do install scripts have specific code to look for that man page?

If it's going to be trouble I can put Error.pm back.  It's just something I
did in passing.

quoted

+# Don't forget to update the perl/Makefile, too.
+# Don't forget to test with NO_PERL_MAKEMAKER=YesPlease

Now the reader will have no reason to be looking at this file, so
these comments are pretty much useless.  In an ideal world, "make
test" in the MakeMaker build would automatically "grep perl/Makefile"
to catch modules that are not listed there, but that can wait, I
imagine.

Alternatively, maybe there could be a perl/modules.list that both
makefiles read?  That way, if I drop in an unrelated .pm file for
reference while coding the build system would not be confused by
it, and since both build systems would use the same module list
there would be no risk of it falling out of date.

Ideally, that second Makefile would go away.  Parallel build systems are extra
work and generate bugs.

The log suggests it might have something to do with people wanting to build
with an ActiveState Perl on Cygwin or something?  MakeMaker builds different
Makefiles depending on the OS, so it may be as simple as telling Makefile.PL
what flavor of make you're using.


-- 
emacs -- THAT'S NO EDITOR... IT'S AN OPERATING SYSTEM!