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

From: Michael G Schwern <schwern@pobox.com>
Date: Jul 18, 2012, 01:41 UTC
Message-ID: <50061435.1090900@pobox.com>
In-Reply-To: <20120718000120.GG25325@burratino>

On 2012.7.17 5:01 PM, Jonathan Nieder wrote:

Show 8 quoted lines

>> 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.

Show 5 quoted lines

> 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.

Show 14 quoted lines

>> +# 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!