Re: reformatted GNUmakefile pushed to staging

[Werner LEMBERG]

>> as discussed some weeks ago, I've now pushed the reformatted
>> GNUmakefile to staging.  There are only whitespace changes.
>
> Is there anything wrong with our review system?  If you feel there
> is, how about at least posting the patch for review on the list
> before pushing?

It *has* been posted for review, and I got positive responses only.
The only issue was that committing should be delayed until 1.16 is
out.

> +TOPDOC_TXT_FILES = \
> +  $(addprefix $(top-build-dir)/Documentation/topdocs/$(outdir)/, \
> +              $(addsuffix .txt, \
> +                          $(TOPDOC_FILES)))
> +IN_FILES := \
> +  $(call src-wildcard, \
> +         *.in)
>
> are quite beyond the scope of discussion and I don't see that they
> improve either readability nor reduce the potential for merge
> conflicts.

For me, they do.  Everything which brings the line length *in a
systematic manner* below 80 characters is good.

> And things like
>
> +STEPMAKE_TEMPLATES = \
> +  po \
> +  install \
> +  toplevel
> +LOCALSTEPMAKE_TEMPLATES = \
> +  lilypond
>
> are ugly without an additional empty line.

Well, there was no empty line before either.  Feel free to add one.

>  Stuff like
>
> -       $(MAKE) local-dist $(distdir)
> +       $(MAKE) local-dist \
> +               $(distdir)
>
> makes little sense: why split a simple command into two lines if
> after the split both the first as well as the second line are
> special (one starts with $(MAKE) and the other does not end with \)?
> Absolutely no gain in readability or mergeability.

I disagree.  The main point of a more vertical formatting is that
future changes can be easily followed.  Just think of adding another
target.  Overlong lines don't work nicely with diff output; sometimes
I search a minute in the gitk window before I find the tiny
difference.

I now believe that the stuff in GNUmakefile.in is `smooth', this is,
the overall appearance is quite similar.  Additionally, I'm quite
certain that there is *no* chance to ever find a formatting which
pleases everyone.

> You _intend_ this change not to contain any functional differences,
> but a rather thorough way to be reasonably sure that you were
> successful in every detail is our regtest system.

You have a point.  I forgot this, sorry.


    Werner