Re: [PATCH 04/17] Makefile: a dry-run can error out if no perl. Document the issue
From: Philip Oakley philipoak...@iee.org Sent: Friday, June 26, 2015 12:34 AM From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com I am not sure what this patch is trying to achieve. I have been able to repeat the issue, more below. It was probably a bit of 'don't mess with working code', given that I'd used the NO_PERL solution, rather 'document the issue' Then this part applies, I think. If you are not touching what this Makefile actually does, then I would imagine that you are running the buildsystems code that actually drives 'make -n' with some available solution (perhaps you are running 'make -n NO_PERL=NoThanks' or something like that)? Then instead of a command like this that nobody would read in this file, the same command can instead go there to explain what the workaround (e.g. unusual-looking 'make -n NO_PERL=NoThanks') is doing? The command sequence: $ git clean -dfx $ make -n MSVC=1 V=1 2ErrsFile.txt 1MakeDry.txt produces the error make[1]: *** No rule to make target 'PM.stamp', needed by 'perl.mak'. Stop. make: *** [perl/perl.mak] Error 2 the actual MakeDry.txt reaches echo $FLAGS GIT-CFLAGS; \ fi make[2]: Leaving directory '/c/msysgit195/git' make[1]: Leaving directory '/c/msysgit195/git/perl' Makefile:1758: recipe for target 'perl/perl.mak' failed My understanding of the error is that, first, the PM.stamp is removed by the clean, then the dryrun has by the error time passed the initial PM.stamp update code, but doesn't execute it (being a dry run), thus the file PM.stamp still does not exist. The makefile then descends into the 'perl/Makefile' pre-requisite to 'perl/perl.mak', and (IIUC) at this point the L25#$(makfile): PM.stamp then barfs because there is no PM.stamp to be a prerequisite for that line. As noted in the patch, my response at the time (not fully understanding why) was simply to annotate the Makefile's PM.stamp (which is where the error would first leads any future debugging). Possibly other options would be to add an extra PM.stamp target which, for a dry-run (+recipe), creates any empty PM.stamp file if one does not exist, simply to allow the perl/perl.mak to succeed. Or perhaps simply add the PM.stamp file to the code (or maybe not). A third option would be to simply convert the PM.stamp recipe to a +recipe so that it's executed during the dry-run, but that may be contrary to the idea of being a dry-run. Do you have any preference for how I should resolve this? Ideally I like to drop the use of the NO_PERL in the dry run. -- Philip I was more of the view that this was about prevention (here), rather than retrospective explanation of the code (there). In my case the errors were showing problems with the PM.stamp in the makefile (I didn't have the solution at that point). So either a short comment # consider using 'NO_PERL=YesPlease' for dry run invocations (beware your double negative ;-), or the addition of the '+recipe', would still be my preferred change, rather than leaving the open manhole for others to fall into. The thread on my difficulties is at $gmane/263656 (2015-02-10 22:51) At the moment I'm getting (on my old WinXP machine, using Msysgit 1.9.5 as a basis) $ make -n MSVC=1 V=1 1makedry.txt make[1]: *** No rule to make target `PM.stamp', needed by `perl.mak'. Stop. make: *** [perl/perl.mak] Error 2 As you can see, at that time the place to look would be the makefile, so I would do think a 'fix' there would still be appropriate. Do you have a preference among the three options (comment, +recipe, drop)? -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/17] Makefile: a dry-run can error out if no perl. Document the issue
Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com I am not sure what this patch is trying to achieve. It was probably a bit of 'don't mess with working code', given that I'd used the NO_PERL solution, rather 'document the issue' Then this part applies, I think. If you are not touching what this Makefile actually does, then I would imagine that you are running the buildsystems code that actually drives 'make -n' with some available solution (perhaps you are running 'make -n NO_PERL=NoThanks' or something like that)? Then instead of a command like this that nobody would read in this file, the same command can instead go there to explain what the workaround (e.g. unusual-looking 'make -n NO_PERL=NoThanks') is doing? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/17] Makefile: a dry-run can error out if no perl. Document the issue
Philip Oakley philipoak...@iee.org writes:
A 'make -n' dry-run is used as part of the /compat/vcbuild and
/contrib/buildsystems code. The commit ee9be06 (perl: detect new files
in MakeMaker builds, 2012-07-27) was not aware of that dry-run usage
and thus would not execute the target.
Add a comment to the make file stating the issue and the available
solutions of either NO_PERL or a '+recipe'.
I am not sure what this patch is trying to achieve.
If you are not touching what this Makefile actually does, then I
would imagine that you are running the buildsystems code that
actually drives 'make -n' with some available solution (perhaps
you are running 'make -n NO_PERL=NoThanks' or something like that)?
Then instead of a command like this that nobody would read in this
file, the same command can instead go there to explain what the
workaround (e.g. unusual-looking 'make -n NO_PERL=NoThanks') is
doing?
I suspect you mean by +recipe that you modify this makefile to make
such a workaround unnecessary? If that is the case, why isn't such
a change actually be done with this commit, instead of a comment?
I am not sure what this patch is trying to achieve.
Puzzled...
Signed-off-by: Philip Oakley philipoak...@iee.org
---
Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Makefile b/Makefile
index 149f1c7..22108bb 100644
--- a/Makefile
+++ b/Makefile
@@ -1746,6 +1746,9 @@ $(SCRIPT_PERL_GEN): perl/perl.mak
perl/perl.mak: perl/PM.stamp
+# 'make -n' (dry-run) will not execute this target which creates/updates the
PM.stamp file.
+# To avoid the error of failing to find the target PM.stamp, either use
NO_PERL=1 (YesPlease),
+# or add a leading '+' to the recipe '+$(QUIET_GEN)$(FIND) perl ...' so that
it is executed.
perl/PM.stamp: FORCE
@$(FIND) perl -type f -name '*.pm' | sort $@+ \
{ cmp $@+ $@ /dev/null 2/dev/null || mv $@+ $@; } \
--
2.3.1
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/17] Makefile: a dry-run can error out if no perl. Document the issue
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com I am not sure what this patch is trying to achieve. It was probably a bit of 'don't mess with working code', given that I'd used the NO_PERL solution, rather 'document the issue' Then this part applies, I think. If you are not touching what this Makefile actually does, then I would imagine that you are running the buildsystems code that actually drives 'make -n' with some available solution (perhaps you are running 'make -n NO_PERL=NoThanks' or something like that)? Then instead of a command like this that nobody would read in this file, the same command can instead go there to explain what the workaround (e.g. unusual-looking 'make -n NO_PERL=NoThanks') is doing? I was more of the view that this was about prevention (here), rather than retrospective explanation of the code (there). In my case the errors were showing problems with the PM.stamp in the makefile (I didn't have the solution at that point). So either a short comment # consider using 'NO_PERL=YesPlease' for dry run invocations (beware your double negative ;-), or the addition of the '+recipe', would still be my preferred change, rather than leaving the open manhole for others to fall into. The thread on my difficulties is at $gmane/263656 (2015-02-10 22:51) At the moment I'm getting (on my old WinXP machine, using Msysgit 1.9.5 as a basis) $ make -n MSVC=1 V=1 1makedry.txt make[1]: *** No rule to make target `PM.stamp', needed by `perl.mak'. Stop. make: *** [perl/perl.mak] Error 2 As you can see, at that time the place to look would be the makefile, so I would do think a 'fix' there would still be appropriate. Do you have a preference among the three options (comment, +recipe, drop)? -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/17] Makefile: a dry-run can error out if no perl. Document the issue
A 'make -n' dry-run is used as part of the /compat/vcbuild and
/contrib/buildsystems code. The commit ee9be06 (perl: detect new files
in MakeMaker builds, 2012-07-27) was not aware of that dry-run usage
and thus would not execute the target.
Add a comment to the make file stating the issue and the available
solutions of either NO_PERL or a '+recipe'.
Signed-off-by: Philip Oakley philipoak...@iee.org
---
Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Makefile b/Makefile
index 149f1c7..22108bb 100644
--- a/Makefile
+++ b/Makefile
@@ -1746,6 +1746,9 @@ $(SCRIPT_PERL_GEN): perl/perl.mak
perl/perl.mak: perl/PM.stamp
+# 'make -n' (dry-run) will not execute this target which creates/updates the
PM.stamp file.
+# To avoid the error of failing to find the target PM.stamp, either use
NO_PERL=1 (YesPlease),
+# or add a leading '+' to the recipe '+$(QUIET_GEN)$(FIND) perl ...' so that
it is executed.
perl/PM.stamp: FORCE
@$(FIND) perl -type f -name '*.pm' | sort $@+ \
{ cmp $@+ $@ /dev/null 2/dev/null || mv $@+ $@; } \
--
2.3.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
