From: Michael G Schwern <schwern@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com, robbat2@gentoo.org,
bwalton@artsci.utoronto.ca, normalperson@yhbt.net
Subject: Re: [PATCH 3/3] The Makefile.PL will now find .pm files itself.
Date: Wed, 25 Jul 2012 14:49:29 -0700 [thread overview]
Message-ID: <501069E9.2000009@pobox.com> (raw)
In-Reply-To: <20120725211143.GA5455@burratino>
On 2012.7.25 2:11 PM, Jonathan Nieder wrote:
>> --- a/perl/Makefile.PL
>> +++ b/perl/Makefile.PL
>> @@ -2,6 +2,10 @@ use strict;
>> use warnings;
>> use ExtUtils::MakeMaker;
>> use Getopt::Long;
>> +use File::Find;
>> +
>> +# Don't forget to update the perl/Makefile, too.
>> +# Don't forget to test with NO_PERL_MAKEMAKER=YesPlease
>
> In a previous apartment I lived in, there was a note taped to the
> lightswitch reminding us to turn off the heat, take keys with us, and
> lock the door. The note was useful because by force of habit we would
> be turning off the light, and as a result see the note, on the way
> out.
>
> Who are these comments in perl/Makefile.PL addressed to?
Somebody adding, renaming or deleting a .pm file.
> Why would such a person be looking at perl/Makefile.PL?
Because sometimes they do wacky things, especially in non-Perl projects, its
good to check.
> Sorry to sound like a broken record, but I don't think these questions
> were answered yet.
The instructions are still necessary and I don't know where to put them so
they have a better chance to be seen. At least somebody adding a .pm file
might glance inside the Makefile.PL.
> How about this patch for squashing in, which would avoid the question
> and save me from having to worry that my words are going to stay in
> this file after the no-makemaker option no longer exists because
> nobody looks at them here?
If somebody eliminates NO_PERL_MAKEMAKER they'd grep the tree for all its
occurrences. I'd rather keep the instructions in there, because having two
build systems is downright wacky. In fact, I'd go on to say that an
explanation should be added to the Makefile as well.
This is out of scope for what I wanted this patch to do, and I really don't
have a horse in this race. For my purposes, I just preserved the comment. If
it goes away that's ok, too.
Later on I can help getting rid of the second build system.
> diff --git i/perl/Makefile.PL w/perl/Makefile.PL
> index 3d88a6b9..377fd042 100644
> --- i/perl/Makefile.PL
> +++ w/perl/Makefile.PL
> @@ -4,9 +4,6 @@ use ExtUtils::MakeMaker;
> use Getopt::Long;
> use File::Find;
>
> -# Don't forget to update the perl/Makefile, too.
> -# Don't forget to test with NO_PERL_MAKEMAKER=YesPlease
> -
> # Sanity: die at first unknown option
> Getopt::Long::Configure qw/ pass_through /;
--
31. Not allowed to let sock puppets take responsibility for any of my
actions.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
next prev parent reply other threads:[~2012-07-25 21:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-25 3:21 Teach Makefile.PL to find .pm files on its own Michael G. Schwern
2012-07-25 3:21 ` [PATCH 1/3] Quiet warning if Makefile.PL is run with -w and no --localedir Michael G. Schwern
2012-07-25 3:21 ` [PATCH 2/3] Don't lose Error.pm if $@ gets clobbered Michael G. Schwern
2012-07-25 3:21 ` [PATCH 3/3] The Makefile.PL will now find .pm files itself Michael G. Schwern
2012-07-25 21:11 ` Jonathan Nieder
2012-07-25 21:31 ` Jonathan Nieder
2012-07-25 21:49 ` Michael G Schwern [this message]
2012-07-25 21:56 ` Jonathan Nieder
2012-07-25 16:56 ` Teach Makefile.PL to find .pm files on its own Junio C Hamano
2012-07-25 20:26 ` Michael G Schwern
2012-07-25 20:32 ` Junio C Hamano
2012-07-25 21:12 ` Michael G Schwern
2012-07-25 22:19 ` Junio C Hamano
2012-07-25 22:56 ` Michael G Schwern
2012-07-25 23:29 ` Junio C Hamano
2012-07-25 23:37 ` Eric Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=501069E9.2000009@pobox.com \
--to=schwern@pobox.com \
--cc=bwalton@artsci.utoronto.ca \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=normalperson@yhbt.net \
--cc=robbat2@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).