git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [PATCH 1/3] Documentation/Makefile: add a commented-out ' to unconfuse Emacs
@ 2009-05-25 22:07 Samuel Bronson
  2009-05-25 22:07 ` [PATCH 2/3] Makefile: Add "make help" telling users to read INSTALL and Makefile Samuel Bronson
  0 siblings, 1 reply; 9+ messages in thread
From: Samuel Bronson @ 2009-05-25 22:07 UTC (permalink / raw)
  To: gitster; +Cc: git, Samuel Bronson

Signed-off-by: Samuel Bronson <naesten@gmail.com>
---
 Documentation/Makefile |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 7a8037f..f5d670e 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -106,6 +106,7 @@ endif
 SHELL_PATH ?= $(SHELL)
 # Shell quote;
 SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
+# unconfuse Emacs: '
 
 #
 # Please note that there is a minor bug in asciidoc.
-- 
1.6.3.1

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH 2/3] Makefile: Add "make help" telling users to read INSTALL and Makefile
  2009-05-25 22:07 [PATCH 1/3] Documentation/Makefile: add a commented-out ' to unconfuse Emacs Samuel Bronson
@ 2009-05-25 22:07 ` Samuel Bronson
  2009-05-25 22:07   ` [PATCH 3/3] Makefile: add commented out 's for Emacs here, too Samuel Bronson
  0 siblings, 1 reply; 9+ messages in thread
From: Samuel Bronson @ 2009-05-25 22:07 UTC (permalink / raw)
  To: gitster; +Cc: git, Samuel Bronson

Without this, "make help" first builds "help.o", then tries to link it to
make a "help" executable, which might take a while to fail in a clean tree.

Signed-off-by: Samuel Bronson <naesten@gmail.com>
---
 Makefile |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index eaae45d..07a141d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,12 @@
 # The default target of this Makefile is...
 all::
 
+.PHONY: help
+help:
+	@echo 'Building:'
+	@echo '  For help on building, see the INSTALL file and the comments at'
+	@echo '  the top of Makefile'
+
 # Define V=1 to have a more verbose compile.
 #
 # Define SNPRINTF_RETURNS_BOGUS if your are on a system which snprintf()
-- 
1.6.3.1

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH 3/3] Makefile: add commented out 's for Emacs here, too
  2009-05-25 22:07 ` [PATCH 2/3] Makefile: Add "make help" telling users to read INSTALL and Makefile Samuel Bronson
@ 2009-05-25 22:07   ` Samuel Bronson
  2009-05-30 13:05     ` Markus Heidelberg
  0 siblings, 1 reply; 9+ messages in thread
From: Samuel Bronson @ 2009-05-25 22:07 UTC (permalink / raw)
  To: gitster; +Cc: git, Samuel Bronson

Signed-off-by: Samuel Bronson <naesten@gmail.com>
---
 Makefile |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 07a141d..b485c21 100644
--- a/Makefile
+++ b/Makefile
@@ -1190,6 +1190,13 @@ prefix_SQ = $(subst ','\'',$(prefix))
 SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
 PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
 TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
+# unconfuse Emacs: '
+
+# The above comment is in case there is an odd number of _SQ
+# definitions above, since they seem to confuse Emacs. If there is an
+# even number of such definitions, it does no harm, since emacs
+# doesn't recognize string delimiters inside recognized comments.
+
 
 LIBS = $(GITLIBS) $(EXTLIBS)
 
@@ -1437,6 +1444,8 @@ cscope:
 ### Detect prefix changes
 TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):\
              $(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
+# unconfuse Emacs: '
+# (see above comment about "unconfuse Emacs")
 
 GIT-CFLAGS: .FORCE-GIT-CFLAGS
 	@FLAGS='$(TRACK_CFLAGS)'; \
@@ -1457,6 +1466,8 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
 ### Detect Tck/Tk interpreter path changes
 ifndef NO_TCLTK
 TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
+# unconfuse Emacs: '
+# (see above comment about "unconfuse Emacs")
 
 GIT-GUI-VARS: .FORCE-GIT-GUI-VARS
 	@VARS='$(TRACK_VARS)'; \
@@ -1540,6 +1551,8 @@ gitexec_instdir = $(prefix)/$(gitexecdir)
 endif
 gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
 export gitexec_instdir
+# unconfuse Emacs: '
+# (see above comment about "unconfuse Emacs")
 
 install: all
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
-- 
1.6.3.1

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH 3/3] Makefile: add commented out 's for Emacs here, too
  2009-05-25 22:07   ` [PATCH 3/3] Makefile: add commented out 's for Emacs here, too Samuel Bronson
@ 2009-05-30 13:05     ` Markus Heidelberg
  2009-05-30 18:37       ` Samuel Bronson
  2009-05-30 19:07       ` Junio C Hamano
  0 siblings, 2 replies; 9+ messages in thread
From: Markus Heidelberg @ 2009-05-30 13:05 UTC (permalink / raw)
  To: Samuel Bronson; +Cc: gitster, git

Samuel Bronson, 26.05.2009:
> Signed-off-by: Samuel Bronson <naesten@gmail.com>
> ---
>  Makefile |   13 +++++++++++++
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 07a141d..b485c21 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1190,6 +1190,13 @@ prefix_SQ = $(subst ','\'',$(prefix))
>  SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
>  PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
>  TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
> +# unconfuse Emacs: '
> +
> +# The above comment is in case there is an odd number of _SQ
> +# definitions above, since they seem to confuse Emacs. If there is an
> +# even number of such definitions, it does no harm, since emacs
> +# doesn't recognize string delimiters inside recognized comments.

This doesn't only confuse Emacs, so the subject should be changed to
something like "... to unconfuse editors' syntax highlighting" and be
squashed with Patch 1/3, since this is exactly the same issue.

I think this is way too much comment and would prefer none at all. I
also would remove the global 4-line comment.

But Vim for example is not satisfied with your fix above. It needs this
workaround for every line and additionally needs a closing parenthesis,
because the real one is hidden in the string. So this would work for
Vim:

 PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
+#')
 TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
+#')

Maybe even behind the concerned line to avoid clutter, if this doesn't
cause other problems:

-PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
+PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))#')
-TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
+TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))#')

But I'm not completely confident of this fix anyway and don't know
whether it should be included at all.

Markus

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 3/3] Makefile: add commented out 's for Emacs here, too
  2009-05-30 13:05     ` Markus Heidelberg
@ 2009-05-30 18:37       ` Samuel Bronson
  2009-05-30 19:07       ` Junio C Hamano
  1 sibling, 0 replies; 9+ messages in thread
From: Samuel Bronson @ 2009-05-30 18:37 UTC (permalink / raw)
  To: markus.heidelberg; +Cc: gitster, git

On Sat, May 30, 2009 at 9:05 AM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:

>> +# The above comment is in case there is an odd number of _SQ
>> +# definitions above, since they seem to confuse Emacs. If there is an
>> +# even number of such definitions, it does no harm, since emacs
>> +# doesn't recognize string delimiters inside recognized comments.
>
> This doesn't only confuse Emacs, so the subject should be changed to
> something like "... to unconfuse editors' syntax highlighting" and be
> squashed with Patch 1/3, since this is exactly the same issue.
>
> I think this is way too much comment and would prefer none at all. I
> also would remove the global 4-line comment.

Okay. I guess I'll save it for the commit message (rewritten to match
the changes suggested below), maybe keep two words for the first one
in each Makefile ...

> But Vim for example is not satisfied with your fix above. It needs this
> workaround for every line and additionally needs a closing parenthesis,
> because the real one is hidden in the string. So this would work for
> Vim:
>
>  PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
> +#')
>  TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
> +#')

Yeah, emacs would work better that way too -- I was going for a
low-disruption patch, and was mostly interested in making sure
unrelated portions of the Makefile didn't get swallowed by
string-coloring. I didn't particularly care about the parentheses --
does Vim care about that for indentation, or just paren-matching?

I wonder why emacs and vim both have the same problem with that
construct ... and how hard it would be to fix. (Thankfully, this
approach to dealing with the breakage will not confuse corrected
versions, since they will basically ignore the contents of the
comments for syntax highlighting purposes :-).

> Maybe even behind the concerned line to avoid clutter, if this doesn't
> cause other problems:
>
> -PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
> +PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))#')
> -TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
> +TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))#')

That should at least work a lot better than my initial attempt at 1/3,
where I had a space before the # -- the space broke the build, which
is actually how I ended up noticing the need for 2/3 .

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 3/3] Makefile: add commented out 's for Emacs here, too
  2009-05-30 13:05     ` Markus Heidelberg
  2009-05-30 18:37       ` Samuel Bronson
@ 2009-05-30 19:07       ` Junio C Hamano
  2009-05-30 22:01         ` Markus Heidelberg
  1 sibling, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2009-05-30 19:07 UTC (permalink / raw)
  To: markus.heidelberg; +Cc: Samuel Bronson, git

Markus Heidelberg <markus.heidelberg@web.de> writes:

>> +# unconfuse Emacs: '
>> +
>> +# The above comment is in case there is an odd number of _SQ
>> +# definitions above, since they seem to confuse Emacs. If there is an
>> +# even number of such definitions, it does no harm, since emacs
>> +# doesn't recognize string delimiters inside recognized comments.
> ...
> I think this is way too much comment and would prefer none at all. I
> also would remove the global 4-line comment.

I personally do not like contaminating our source files with this kind of
magic crufts just to please broken tools, be they emacs or vim.  I would
hate them even more if they are not clearly commented why they exist for
two reasons.

 (1) without clear instructions ("odd number of ..." is not quite enough),
     people who do *not* use broken tools cannot keep them up-to-date when
     they make modifications;

 (2) when broken tools are finally fixed, nobody would remember why the
     magic crufts exist, and they will end up staying in the source for a
     long time.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 3/3] Makefile: add commented out 's for Emacs here, too
  2009-05-30 19:07       ` Junio C Hamano
@ 2009-05-30 22:01         ` Markus Heidelberg
  2013-12-19 23:37           ` Samuel Bronson
  0 siblings, 1 reply; 9+ messages in thread
From: Markus Heidelberg @ 2009-05-30 22:01 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Samuel Bronson, git

Junio C Hamano, 30.05.2009:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
> 
> >> +# unconfuse Emacs: '
> >> +
> >> +# The above comment is in case there is an odd number of _SQ
> >> +# definitions above, since they seem to confuse Emacs. If there is an
> >> +# even number of such definitions, it does no harm, since emacs
> >> +# doesn't recognize string delimiters inside recognized comments.
> > ...
> > I think this is way too much comment and would prefer none at all. I
> > also would remove the global 4-line comment.
> 
> I personally do not like contaminating our source files with this kind of
> magic crufts just to please broken tools [...]

Neither do I like it. That's why I wrote, I wasn't sure whether this
should be applied.

In the buildroot project (it consists of Makefiles) there a lots of
those workarounds. There was a patch on the list to replace all
$(strip $(subst ",,$(FOO))) with $(call strip_dquotes, $(FOO)), but
$(call) is not allowed in git for compatibility reasons.

Markus

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 3/3] Makefile: add commented out 's for Emacs here, too
  2009-05-30 22:01         ` Markus Heidelberg
@ 2013-12-19 23:37           ` Samuel Bronson
  2013-12-19 23:52             ` Jonathan Nieder
  0 siblings, 1 reply; 9+ messages in thread
From: Samuel Bronson @ 2013-12-19 23:37 UTC (permalink / raw)
  To: markus.heidelberg; +Cc: Junio C Hamano, git

On Sat, May 30, 2009 at 6:01 PM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:

> In the buildroot project (it consists of Makefiles) there a lots of
> those workarounds. There was a patch on the list to replace all
> $(strip $(subst ",,$(FOO))) with $(call strip_dquotes, $(FOO)), but
> $(call) is not allowed in git for compatibility reasons.

Hmm.  What compatibility reasons, and are they still applicable?

[If you're wondering why I'm revisiting this, I was looking through my
branches for anything outstanding and found this patch series there.]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 3/3] Makefile: add commented out 's for Emacs here, too
  2013-12-19 23:37           ` Samuel Bronson
@ 2013-12-19 23:52             ` Jonathan Nieder
  0 siblings, 0 replies; 9+ messages in thread
From: Jonathan Nieder @ 2013-12-19 23:52 UTC (permalink / raw)
  To: Samuel Bronson; +Cc: markus.heidelberg, Junio C Hamano, git

Hi,

Samuel Bronson wrote:
> Markus Heidelberg wrote:

>> In the buildroot project (it consists of Makefiles) there a lots of
>> those workarounds. There was a patch on the list to replace all
>> $(strip $(subst ",,$(FOO))) with $(call strip_dquotes, $(FOO)), but
>> $(call) is not allowed in git for compatibility reasons.
>
> Hmm.  What compatibility reasons, and are they still applicable?

Good question.

  $ git log -1 -S'$(call ' -- Makefile 
  commit 39c015c556f285106931e0500f301de462b0e46e
  Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
  Date:   Sat Feb 18 12:40:22 2006 +0100

      Fixes for ancient versions of GNU make

      Some versions of GNU make do not understand $(call), and have problems to
      interpret rules like this:

      some_target: CFLAGS += -Dsome=defs

      [jc: simplified substitution a bit. ]

      Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
      Signed-off-by: Junio C Hamano <junkio@cox.net>

A quick gmane search finds [1], which suggests the "make" where this
problem came up was on IRIX.  I don't have a strong opinion either way
about whether such ancient 'make' is worth supporting (as a practical
matter, it's hard to keep testing and make sure such support still
works).

Would $(call) simplify the makefile much?

Thanks,
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/16344
http://thread.gmane.org/gmane.comp.version-control.git/16345/focus=16375
http://thread.gmane.org/gmane.comp.version-control.git/48968/focus=49117

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2013-12-19 23:53 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-25 22:07 [PATCH 1/3] Documentation/Makefile: add a commented-out ' to unconfuse Emacs Samuel Bronson
2009-05-25 22:07 ` [PATCH 2/3] Makefile: Add "make help" telling users to read INSTALL and Makefile Samuel Bronson
2009-05-25 22:07   ` [PATCH 3/3] Makefile: add commented out 's for Emacs here, too Samuel Bronson
2009-05-30 13:05     ` Markus Heidelberg
2009-05-30 18:37       ` Samuel Bronson
2009-05-30 19:07       ` Junio C Hamano
2009-05-30 22:01         ` Markus Heidelberg
2013-12-19 23:37           ` Samuel Bronson
2013-12-19 23:52             ` Jonathan Nieder

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).