Trim unused toplevel targets. (issue 547810069 by hanwenn@gmail.com)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Trim unused toplevel targets. (issue 547810069 by hanwenn@gmail.com)

Dev mailing list
LGTM


https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in
File GNUmakefile.in (right):

https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in#newcode26
GNUmakefile.in:26: RELEASE_FILES = RELEASE-COMMIT
Many GNU packages auto-generate a ChangeLog file from the git commit
messages.  Shall we do something similar?

https://codereview.appspot.com/547810069/

Reply | Threaded
Open this post in threaded view
|

Re: Trim unused toplevel targets. (issue 547810069 by hanwenn@gmail.com)

Han-Wen Nienhuys-3
Reviewers: lemzwerg,

Message:
On 2020/03/22 05:51:34, lemzwerg wrote:
> LGTM
>
> https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in
> File GNUmakefile.in (right):
>
>
https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in#newcode26
> GNUmakefile.in:26: RELEASE_FILES = RELEASE-COMMIT
> Many GNU packages auto-generate a ChangeLog file from the git commit
messages.
> Shall we do something similar?

What is the ChangeLog used for these days?

Many GNU packages haven't been with the times. Git is now 14 years old.
I people want to know what changed, they can read the man page to
git-log.

Description:
Trim unused toplevel targets.

Please review this at https://codereview.appspot.com/547810069/

Affected files (+3, -15 lines):
  M GNUmakefile.in


Index: GNUmakefile.in
diff --git a/GNUmakefile.in b/GNUmakefile.in
index 42b62683302441b1fbcb14a8b0a8433397e86d4d..850bd8b5f0d3e4b37cb8b9977c10da369c0f2c53 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -23,7 +23,7 @@ TOPDOC_FILES = AUTHORS INSTALL README NEWS
 TOPDOC_TXT_FILES = $(addprefix $(top-build-dir)/Documentation/topdocs/$(outdir)/,$(addsuffix .txt,$(TOPDOC_FILES)))
 IN_FILES := $(call src-wildcard,*.in)
 
-RELEASE_FILES = ChangeLog RELEASE-COMMIT
+RELEASE_FILES = RELEASE-COMMIT
 RELEASE_OUT_FILES = $(RELEASE_FILES:%=$(outdir)/%)
 OUT_DIST_FILES += $(RELEASE_OUT_FILES)
 INSTALLATION_DIR=$(local_lilypond_datadir)
@@ -78,15 +78,10 @@ $(outdir)/VERSION: $(config_make) VERSION
  -mkdir -p $(outdir)
  echo $(TOPLEVEL_VERSION) > $@
 
-$(outdir)/ChangeLog: $(outdir)/VERSION
- $(call ly_progress,Making,$@,)
- @echo 'See http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=log;h=refs/tags/release/$(TOPLEVEL_VERSION)-1' > $@
-
-$(outdir)/RELEASE-COMMIT: # FIXME: any file in $(top-src-dir)/.git/ we can depend on and be sure RELEASE-COMMIT is up to date?
+$(outdir)/RELEASE-COMMIT:
  $(call ly_progress,Making,$@,)
  git --git-dir=$(top-src-dir)/.git show HEAD | head -100 > $@
 
-# junk me as soon as RELEASE-COMMIT FIXME: has been addressed
 refresh-release-files:
  test -d $(top-src-dir)/.git && rm -f $(RELEASE_OUT_FILES)
  $(MAKE) $(RELEASE_OUT_FILES)
@@ -97,10 +92,7 @@ python-modules:
 
 top-doc: python-modules
 
-local-clean: local-clean-ChangeLog local-clean-filelist
-
-local-clean-ChangeLog:
- rm -f ChangeLog
+local-clean: local-clean-filelist
 
 info:
  $(foreach d, $(INFO_DIRECTORIES),$(MAKE) -C $(d) out=www info && ) true
@@ -195,10 +187,6 @@ tree-share = $(tree-prefix)/share
 tree-share-prefix = $(tree-share)/lilypond/current
 tree-lib-prefix = $(tree-lib)/lilypond/current
 
-C_DIRS = flower lily
-c-clean:
- $(foreach i, $(C_DIRS), $(MAKE) -C $(i) clean &&) true
-
 src-ext = c cc yy ll hh icc py scm tex ps texi itexi tely itely sh
 
 doc-clean: snippets-clean $(tree-share-prefix)/lilypond-force



Reply | Threaded
Open this post in threaded view
|

Re: Trim unused toplevel targets. (issue 547810069 by hanwenn@gmail.com)

Han-Wen Nienhuys-3
In reply to this post by Dev mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Trim unused toplevel targets. (issue 547810069 by hanwenn@gmail.com)

David Kastrup
In reply to this post by Han-Wen Nienhuys-3
[hidden email] writes:

> Reviewers: lemzwerg,
>
> Message:
> On 2020/03/22 05:51:34, lemzwerg wrote:
>> LGTM
>>
>> https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in
>> File GNUmakefile.in (right):
>>
>>
> https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in#newcode26
>> GNUmakefile.in:26: RELEASE_FILES = RELEASE-COMMIT
>> Many GNU packages auto-generate a ChangeLog file from the git commit
> messages.
>> Shall we do something similar?
>
> What is the ChangeLog used for these days?

Checking what changes are relevant for the distributed version.

> Many GNU packages haven't been with the times. Git is now 14 years old.
> I people want to know what changed, they can read the man page to
> git-log.

That assumes that they don't have an official and versioned distribution
of LilyPond (or of some fork of it) but rather a clone of the repository
corresponding to their version of Git.  The GPL does not guarantee that
modified source comes with full repository access to back it.  Merely
the _current_ corresponding source.

That's the reason "many GNU packages auto-generate a ChangeLog file from
the git commit messages".  The decision to do that has been made after
considerable discussion and the respective tools have been developed.

It's not like decision and implementation of such a policy would happen
in a vacuum and be unprecedented, so the cost of implementing such a
policy would be considerably more moderate than if we had to do it from
scratch.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Trim unused toplevel targets. (issue 547810069 by hanwenn@gmail.com)

Han-Wen Nienhuys-3
On Wed, Mar 25, 2020 at 4:12 PM David Kastrup <[hidden email]> wrote:

>
> [hidden email] writes:
>
> > Reviewers: lemzwerg,
> >
> > Message:
> > On 2020/03/22 05:51:34, lemzwerg wrote:
> >> LGTM
> >>
> >> https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in
> >> File GNUmakefile.in (right):
> >>
> >>
> > https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in#newcode26
> >> GNUmakefile.in:26: RELEASE_FILES = RELEASE-COMMIT
> >> Many GNU packages auto-generate a ChangeLog file from the git commit
> > messages.
> >> Shall we do something similar?
> >
> > What is the ChangeLog used for these days?
>
> Checking what changes are relevant for the distributed version.
>
> > Many GNU packages haven't been with the times. Git is now 14 years old.
> > I people want to know what changed, they can read the man page to
> > git-log.
>
> That assumes that they don't have an official and versioned distribution
> of LilyPond (or of some fork of it) but rather a clone of the repository
> corresponding to their version of Git.  The GPL does not guarantee that
> modified source comes with full repository access to back it.  Merely
> the _current_ corresponding source.
>
> That's the reason "many GNU packages auto-generate a ChangeLog file from
> the git commit messages".  The decision to do that has been made after
> considerable discussion and the respective tools have been developed.


This is all nice and dandy, but

$ tar tfz ~/Downloads/lilypond-2.20.0.tar.gz lilypond-2.20.0/|grep -i changelog
lilypond-2.20.0/out/ChangeLog
lilypond-2.20.0/Documentation/misc/ChangeLog-2.10
lilypond-2.20.0/Documentation/misc/ChangeLog-1.5
lilypond-2.20.0/Documentation/misc/ChangeLog-2.3
lilypond-2.20.0/Documentation/misc/ChangeLog-2.1

ie. the ChangeLog is in a place where nobody can find it, and

$ cat lilypond-2.20.0/out/ChangeLog
See http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=log;h=refs/tags/release/2.20.0-1

it just contains a link, to a paged  version of our log. Good luck
making sense of that.

Local modifications will never produce the right ChangeLog content,
because only we can push commits and tags to savannah.

It has been like this since forever; this mechanism was introduced in
2009, and 2.14.0 (released in 2011) ships a ChangeLog like this in the
out/ directory.

Given that nobody has complained about this undiscoverable and useless
ChangeLog for over 9 years, I think it is safe to remove it.


> It's not like decision and implementation of such a policy would happen
> in a vacuum and be unprecedented, so the cost of implementing such a
> policy would be considerably more moderate than if we had to do it from
> scratch.

I think you are overestimating the amount of careful thought that went
into this.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen

Reply | Threaded
Open this post in threaded view
|

Re: Trim unused toplevel targets. (issue 547810069 by hanwenn@gmail.com)

David Kastrup
Han-Wen Nienhuys <[hidden email]> writes:

> On Wed, Mar 25, 2020 at 4:12 PM David Kastrup <[hidden email]> wrote:
>>
>> [hidden email] writes:
>>
>> > Reviewers: lemzwerg,
>> >
>> > Message:
>> > On 2020/03/22 05:51:34, lemzwerg wrote:
>> >> LGTM
>> >>
>> >> https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in
>> >> File GNUmakefile.in (right):
>> >>
>> >>
>> > https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in#newcode26
>> >> GNUmakefile.in:26: RELEASE_FILES = RELEASE-COMMIT
>> >> Many GNU packages auto-generate a ChangeLog file from the git commit
>> > messages.
>> >> Shall we do something similar?
>> >
>> > What is the ChangeLog used for these days?
>>
>> Checking what changes are relevant for the distributed version.
>>
>> > Many GNU packages haven't been with the times. Git is now 14 years old.
>> > I people want to know what changed, they can read the man page to
>> > git-log.
>>
>> That assumes that they don't have an official and versioned distribution
>> of LilyPond (or of some fork of it) but rather a clone of the repository
>> corresponding to their version of Git.  The GPL does not guarantee that
>> modified source comes with full repository access to back it.  Merely
>> the _current_ corresponding source.
>>
>> That's the reason "many GNU packages auto-generate a ChangeLog file from
>> the git commit messages".  The decision to do that has been made after
>> considerable discussion and the respective tools have been developed.
>
>
> This is all nice and dandy, but
>
> $ tar tfz ~/Downloads/lilypond-2.20.0.tar.gz lilypond-2.20.0/|grep -i changelog
> lilypond-2.20.0/out/ChangeLog
> lilypond-2.20.0/Documentation/misc/ChangeLog-2.10
> lilypond-2.20.0/Documentation/misc/ChangeLog-1.5
> lilypond-2.20.0/Documentation/misc/ChangeLog-2.3
> lilypond-2.20.0/Documentation/misc/ChangeLog-2.1
>
> ie. the ChangeLog is in a place where nobody can find it, and

That would be reason to fix it?

> $ cat lilypond-2.20.0/out/ChangeLog
> See http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=log;h=refs/tags/release/2.20.0-1
>
> it just contains a link, to a paged  version of our log. Good luck
> making sense of that.

This is the (intended) consequence of
commit 525fcaecb829de8c680ad36151d8532da8e35219
Author: Jan Nieuwenhuizen <[hidden email]>
Date:   Wed Jan 14 12:24:47 2009 +0100

    Add missing ChangeLog file with web marker only.

I agree that this does not make a whole lot of sense since it cannot
provide any useful information for anything not released from the
central repository.

Autogenerating the ChangeLog, in contrast, would decouple the tarball
from the Git repository.

> Given that nobody has complained about this undiscoverable and useless
> ChangeLog for over 9 years, I think it is safe to remove it.

It's not useless as such (the link is useful) but it is useless for the
purpose of providing a change history if anybody desires to work with
it.  It is worth noting that the explicit requirement to mark/list all
changes prominently is part of GPLv2 but no longer of GPLv3.

GNU Coding standards
<https://www.gnu.org/prep/standards/standards.html#Change-Log-Concepts>
state:

    Instead of using a file named ChangeLog, you can record the change
    log information as log entries in a version control system such as
    RCS or CVS. This can be converted automatically to a ChangeLog file
    using rcs2log; in Emacs, the command C-x v a (vc-update-change-log)
    does the job.

The choice of listed version control systems makes clear that this text
likely comes from a time before distributed version control systems.

I know that Emacs autogenerates its (GNU standard format) ChangeLog
files from the Git commit messages, but I think that this requires
generally adhering to the kind of formatting you want to end up seeing
in the ChangeLog.

>> It's not like decision and implementation of such a policy would
>> happen in a vacuum and be unprecedented, so the cost of implementing
>> such a policy would be considerably more moderate than if we had to
>> do it from scratch.
>
> I think you are overestimating the amount of careful thought that went
> into this.

The Emacs developer community is large enough that one can with some
confidence assume that not all of them are idiots.  And if they managed
to converge on a solution that they consider reasonably painless for
that purpose, at least taking a look does not seem outlandish.

--
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Reply | Threaded
Open this post in threaded view
|

Re: Trim unused toplevel targets. (issue 547810069 by hanwenn@gmail.com)

Han-Wen Nienhuys-3
On Thu, Mar 26, 2020 at 12:26 PM David Kastrup <[hidden email]> wrote:

> >> > Many GNU packages haven't been with the times. Git is now 14 years old.
> >> > I people want to know what changed, they can read the man page to
> >> > git-log.
> >>
> >> That assumes that they don't have an official and versioned distribution
> >> of LilyPond (or of some fork of it) but rather a clone of the repository
> >> corresponding to their version of Git.  The GPL does not guarantee that
> >> modified source comes with full repository access to back it.  Merely
> >> the _current_ corresponding source.
> >>
> >> That's the reason "many GNU packages auto-generate a ChangeLog file from
> >> the git commit messages".  The decision to do that has been made after
> >> considerable discussion and the respective tools have been developed.
> >
> >
> > This is all nice and dandy, but
> >
> > $ tar tfz ~/Downloads/lilypond-2.20.0.tar.gz lilypond-2.20.0/|grep -i changelog
> > lilypond-2.20.0/out/ChangeLog
> > lilypond-2.20.0/Documentation/misc/ChangeLog-2.10
> > lilypond-2.20.0/Documentation/misc/ChangeLog-1.5
> > lilypond-2.20.0/Documentation/misc/ChangeLog-2.3
> > lilypond-2.20.0/Documentation/misc/ChangeLog-2.1
> >
> > ie. the ChangeLog is in a place where nobody can find it, and
>
> That would be reason to fix it?

The deeper reason is that I'm trying to improve the build system. This
will take the form of a rewrite.  In that context, it's useful to
remove as much unnecessary cruft from the current build system as
possible, so it is clear what is needs to be redone. The
almost-useless ChangeLog in a non-discoverable place is an example of
such cruft.

> > $ cat lilypond-2.20.0/out/ChangeLog
> > See http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=log;h=refs/tags/release/2.20.0-1
> >
> > it just contains a link, to a paged  version of our log. Good luck
> > making sense of that.
>
> This is the (intended) consequence of
> commit 525fcaecb829de8c680ad36151d8532da8e35219
> Author: Jan Nieuwenhuizen <[hidden email]>
> Date:   Wed Jan 14 12:24:47 2009 +0100
>
>     Add missing ChangeLog file with web marker only.
>
> I agree that this does not make a whole lot of sense since it cannot
> provide any useful information for anything not released from the
> central repository.
>
> Autogenerating the ChangeLog, in contrast, would decouple the tarball
> from the Git repository.

This only true in theory. In practice, the ChangeLog doesn't provide
enough information to reconstruct what happened to a file. If a
distribution packager encounters a problem, they are much more likely
to use git-blame and git-log to find out what changed, for what
reason.

> > Given that nobody has complained about this undiscoverable and useless
> > ChangeLog for over 9 years, I think it is safe to remove it.
>
> It's not useless as such (the link is useful) but it is useless for the
> purpose of providing a change history if anybody desires to work with
> it.  It is worth noting that the explicit requirement to mark/list all
> changes prominently is part of GPLv2 but no longer of GPLv3.
>
> GNU Coding standards
> <https://www.gnu.org/prep/standards/standards.html#Change-Log-Concepts>
> state:
>
>     Instead of using a file named ChangeLog, you can record the change
>     log information as log entries in a version control system such as
>     RCS or CVS. This can be converted automatically to a ChangeLog file
>     using rcs2log; in Emacs, the command C-x v a (vc-update-change-log)
>     does the job.
>
> The choice of listed version control systems makes clear that this text
> likely comes from a time before distributed version control systems.
>
> I know that Emacs autogenerates its (GNU standard format) ChangeLog
> files from the Git commit messages, but I think that this requires
> generally adhering to the kind of formatting you want to end up seeing
> in the ChangeLog.

I think you are saying here, that it's OK for us to remove the
ChangeLog from the perspective of GNU standards and our license.

> >> It's not like decision and implementation of such a policy would
> >> happen in a vacuum and be unprecedented, so the cost of implementing
> >> such a policy would be considerably more moderate than if we had to
> >> do it from scratch.
> >
> > I think you are overestimating the amount of careful thought that went
> > into this.
>
> The Emacs developer community is large enough that one can with some
> confidence assume that not all of them are idiots.  And if they managed
> to converge on a solution that they consider reasonably painless for
> that purpose, at least taking a look does not seem outlandish.

It involves a 300 line perl program,

https://github.com/emacs-mirror/emacs/blob/ac242ed3843e127c1e2e506ecfd1a4552a2a8c44/build-aux/gitlog-to-changelog

The output looks like

2020-03-01  Werner Lemberg  <[hidden email]>

        Issue 5795: NR: Improve color table layout

2020-02-29  Dan Eble  <[hidden email]>

        Issue 5790/8: Rational: to_int () becomes trunc_int ()
        ... and returns I64 like num () and den ().

        Issue 5790/7: Rational: disable implicit conversion to double
        This helps emphasize places where exactness might be lost.

ie. the 'changelog' doesn't list the files that were affected by the
changes, so it seems fairly useless to me.

I stand by my proposal to remove our current support for this.

If anyone else cares enough about GNU style ChangeLogs, they can
propose a change to re-introduce them in a more useful form.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen