Emacs pretest 26.1.91 is out

Emacs pretest 26.1.91 is out

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Hi!

The second pretest for what will be the 26.2 release of Emacs
(the extensible text editor) is available at

  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1.91.tar.xz

You can get the PGP signature at

  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1.91.tar.xz.sig

Please give it as much testing as you can.

As always, if you encounter problems building or using Emacs,
send a report to bug-gnu-emacs@gnu.org with full details
(if possible, use M-x report-emacs-bug).

Thanks for helping to test Emacs.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Emacs pretest 26.1.91 is out

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

>>>>> "NP" == Nicolas Petton <nicolas@petton.fr> writes:

NP> The second pretest for what will be the 26.2 release of Emacs
NP> (the extensible text editor) is available at
NP>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1.91.tar.xz

Thanks you, Nicolas!

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Emacs pretest 26.1.91 is out

[Glenn Morris]

Diffing against the previous pretest tarfile (always useful) reveals an
extraneous src/stamp-h.in. This file was deleted two years ago in
2f89350, before the emacs-26 branch was even created.

Re: Emacs pretest 26.1.91 is out

[Nicolas Petton]

On January 7, 2019 11:11:27 PM GMT+01:00, Glenn Morris <rgm@gnu.org> wrote:
>
>Diffing against the previous pretest tarfile (always useful) reveals an
>extraneous src/stamp-h.in. This file was deleted two years ago in
>2f89350, before the emacs-26 branch was even created.

Thanks Glenn for catching this.

Indeed this file should not have been in the tarball, I'll diff the tarballs next time.  

I can also make another pretest now.

Cheers,
Nico

Re: Emacs pretest 26.1.91 is out

[Paul Eggert]

On 1/7/19 2:11 PM, Glenn Morris wrote:
> Diffing against the previous pretest tarfile (always useful) reveals an
> extraneous src/stamp-h.in. This file was deleted two years ago in
> 2f89350, before the emacs-26 branch was even created.
>

While we're on the subject of what goes into the distribution, several 
files are under version control but are not in the distribution tarball. 
They are:


.gitattributes
.gitignore
.gitlab-ci.yml
GNUmakefile
INSTALL.REPO
build-aux/git-hooks/commit-msg
build-aux/git-hooks/pre-commit
msdos/autogen

plus the entire 'test' subdirectory. Shouldn't we be distributing all 
the actual source that we develop with, even if it's not needed to build 
the tarball? That would seem to be more the GNU Way.

Re: Emacs pretest 26.1.91 is out

[Paul Eggert]

On 1/7/19 8:10 AM, Nicolas Petton wrote:
> The second pretest for what will be the 26.2 release of Emacs
> (the extensible text editor) is available at
>
>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1.91.tar.xz
>
> You can get the PGP signature at
>
>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1.91.tar.xz.sig

Thanks for doing that. In the future, would you please announce URLs 
like the following instead?

https://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1.91.tar.xz

Granted, if one checks the PGP signature then FTP will do, but lots of 
people don't bother with checking signatures and HTTPS is more secure in 
that situation. Thanks.

Re: Emacs pretest 26.1.91 is out

[Eli Zaretskii]

> Date: Tue, 08 Jan 2019 00:03:08 +0100
> From: Nicolas Petton <nico@petton.fr>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> I can also make another pretest now.

I don't think this minor issue warrants another pretest just to fix
it.

Re: Emacs pretest 26.1.91 is out

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

Paul Eggert <eggert@cs.ucla.edu> writes:

Hi Paul,

> Thanks for doing that. In the future, would you please announce URLs 
> like the following instead?
>
> https://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1.91.tar.xz
>
> Granted, if one checks the PGP signature then FTP will do, but lots of 
> people don't bother with checking signatures and HTTPS is more secure in 
> that situation. Thanks.

Sure, I can do that.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Emacs pretest 26.1.91 is out

[Phillip Lord]

Windows binaries for this release are now available at:

https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-26/

Independently, I've also updated the Emacs-27 snapshot binaries.

https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/

Phil

Nicolas Petton <nicolas@petton.fr> writes:

> Hi!
>
> The second pretest for what will be the 26.2 release of Emacs
> (the extensible text editor) is available at
>
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1.91.tar.xz
>
> You can get the PGP signature at
>
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1.91.tar.xz.sig
>
> Please give it as much testing as you can.
>
> As always, if you encounter problems building or using Emacs,
> send a report to bug-gnu-emacs@gnu.org with full details
> (if possible, use M-x report-emacs-bug).
>
> Thanks for helping to test Emacs.
>
> Cheers,
> Nico

Re: Emacs pretest 26.1.91 is out

[Glenn Morris]

Paul Eggert wrote:

> While we're on the subject of what goes into the distribution, several
> files are under version control but are not in the distribution
> tarball. They are:
>
>
> .gitattributes
> .gitignore
> .gitlab-ci.yml

Only relevant to git checkouts.

> GNUmakefile

I don't know.

> INSTALL.REPO
> build-aux/git-hooks/commit-msg
> build-aux/git-hooks/pre-commit

Only relevant to git checkouts.

> msdos/autogen

Only relevant to the MS-DOS port maintainer.

> plus the entire 'test' subdirectory.

This has been intentional but it's obviously the most debatable omission.

> Shouldn't we be distributing all the actual source that we develop
> with, even if it's not needed to build the tarball? That would seem to
> be more the GNU Way.

The current philosophy is "omit things that aren't relevant".
I dunno.

Re: Emacs pretest 26.1.91 is out

[Paul Eggert]

On 1/10/19 5:03 PM, Glenn Morris wrote:
> The current philosophy is "omit things that aren't relevant".

Sure, but the question is "What's relevant?" and the answer depends on 
the audience. For example, .gitignore is relevant to anybody who checks 
a tarball's files into a fresh Git repository, and msdos/autogen is 
relevant to anybody who does serious development on MS-DOS regardless of 
whether they're using Git. For each of the nondistributed source files, 
one can make a case that the file is relevant in some cases.

A simple answer to "What's relevant?" is "every source file that's in 
the repository, plus all files generated by 'make' that are useful on 
all platforms". This answer would mean that all the files I mentioned 
should be in the distribution tarball. If the answer to "What's 
relevant?" is something else, then (a) I'm not sure what the answer is 
and (b) whatever the answer is, it's likely complicated and that 
complexity has a maintenance cost.

what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Glenn Morris]

Paul Eggert wrote:

> On 1/10/19 5:03 PM, Glenn Morris wrote:
>> The current philosophy is "omit things that aren't relevant".
>
> Sure, but the question is "What's relevant?" and the answer depends on
> the audience. For example, .gitignore is relevant to anybody who
> checks a tarball's files into a fresh Git repository,

(and then builds in place)

> and msdos/autogen is relevant to anybody who does serious development
> on MS-DOS regardless of whether they're using Git.

I doubt such people exist, for either example.

I see zero practical advantages to a switch to a "distribute everything"
approach (which Emacs has never done, and nor when I check do eg tar,
texinfo, coreutils); unless it will drastically simplify make-dist and
avoid problems like the one fixed in 021f34b. If it does then I am all
for it. :)

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Mike Kupfer]

Glenn Morris wrote:

> Paul Eggert wrote:
> 
> > For example, .gitignore is relevant to anybody who
> > checks a tarball's files into a fresh Git repository,
> 
> (and then builds in place)
[...]
> I doubt such people exist, for either example.

When I unpack an Emacs tarball, I usually check it into a fresh
Mercurial repo before building.  So I wouldn't be surprised to see
someone do that with Git.  (Or am I misunderstanding the example?)

mike

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Stefan Monnier]

> When I unpack an Emacs tarball, I usually check it into a fresh
> Mercurial repo before building.

Interesting.  I wonder why you do that.

To me, if I wanted to have a backing VCS, I'd start from a `git clone`
rather than a tarball.

Is it because you deal with many packages and it's easier to find their
tarballs than to find the repository and the tag that corresponds to
a particular release?  Still, why bother with a VCS?


        Stefan

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Mike Kupfer]

Stefan Monnier wrote:

> > When I unpack an Emacs tarball, I usually check it into a fresh
> > Mercurial repo before building.
> 
> Interesting.  I wonder why you do that.

It's so I can apply in-progress patches using Mercurial Queues (MQ).

> To me, if I wanted to have a backing VCS, I'd start from a `git clone`
> rather than a tarball.

Maybe there's an easy way to manage this with Git, but I don't see one.
First, I want to build, with the patches, on multiple systems.  That
means rebasing is out, or at least it becomes more of a hassle.  Second,
the patches are usually independent.  So, IIUC, the "correct" approach
would be to have a branch for each patch, plus another branch to merge
all the per-patch branches, so that I can build with them all.

With MQ the workflow is pretty simple:

  - unpack the tarball
  - create the repo and commit the unpacked files
  - pull the patches from their repo
  - apply the patches ("hg qpush -a")
  - build

mike

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Stefan Monnier]

> With MQ the workflow is pretty simple:
>
>   1- unpack the tarball
>   2- create the repo and commit the unpacked files
>   3- pull the patches from their repo
>   4- apply the patches ("hg qpush -a")
>   5- build

[ The step 0 being "download the tarball".  ]

Hmm... ignoring the issue of Mercurial -vs- Git, the equivalent using
the VCS would be:

    0- clone from the remote repository to a local "bare" repository.
    1- clone from that local repository
    2- do nothing
    3- pull the patches from their repo
    4- apply the patches
    5- build

Step 0 is where you'll need/want to convert from the remote VCS format
(Git/Mercurial/...) to the one you want to use locally (Mercurial in
your case), so that's where the issue of repository format may get in
the way (I've used Git to access Mercurial repositories and it works OK,
but is significantly slower on large repositories, haven't tried the
other direction).


        Stefan "to me, source code without its VCS repository feels like
                a computer without connection to the Internet"


PS: I should stop here because I'm starting to sound like I'm trying to
convince you to change your workflow, whereas I'm only trying to
understand your motivation.

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Eli Zaretskii]

> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> Date: Thu, 17 Jan 2019 16:18:03 -0800
> Cc: emacs-devel@gnu.org
> 
> Stefan Monnier wrote:
> 
> > > When I unpack an Emacs tarball, I usually check it into a fresh
> > > Mercurial repo before building.
> > 
> > Interesting.  I wonder why you do that.
> 
> It's so I can apply in-progress patches using Mercurial Queues (MQ).
> 
> > To me, if I wanted to have a backing VCS, I'd start from a `git clone`
> > rather than a tarball.
> 
> Maybe there's an easy way to manage this with Git, but I don't see one.

Does the below give any useful ideas?

  https://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Glenn Morris]

Mike Kupfer wrote:

> When I unpack an Emacs tarball, I usually check it into a fresh
> Mercurial repo before building.  So I wouldn't be surprised to see
> someone do that with Git.  (Or am I misunderstanding the example?)

Seems strange to me, but if you think it would help such people to have
.gitignore in the tarfile, feel free to add it.

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Mike Kupfer]

Eli Zaretskii wrote:

> Does the below give any useful ideas?
> 
>   https://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq

Yes, there are a couple packages named there that look worth
investigating.

thanks,
mike

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Mike Kupfer]

Stefan Monnier wrote:

> > With MQ the workflow is pretty simple:
> >
> >   1- unpack the tarball
> >   2- create the repo and commit the unpacked files
> >   3- pull the patches from their repo
> >   4- apply the patches ("hg qpush -a")
> >   5- build
> 
> [ The step 0 being "download the tarball".  ]
> 
> Hmm... ignoring the issue of Mercurial -vs- Git, the equivalent using
> the VCS would be:
> 
>     0- clone from the remote repository to a local "bare" repository.
>     1- clone from that local repository
>     2- do nothing
>     3- pull the patches from their repo
>     4- apply the patches
>     5- build

Yeah, if all I were doing was applying static patches, there would be
less benefit to using MQ.  But MQ helps with the tedium of managing a
patch repo as I refine the patches.  (And I'm probably biased, since
I've been using Mercurial for over 10 years, but I only started using
Git when Emacs moved to it.)

> (I've used Git to access Mercurial repositories and it works OK,
> but is significantly slower on large repositories, haven't tried the
> other direction).

Sometime a few years ago I used a Mercurial extension to access a Git
repo.  I had pretty much the same experience: it worked okay but was
kinda slow.  I don't know if that extension is still available or
maintained.

cheers,
mike

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Stefan Monnier]

>> > With MQ the workflow is pretty simple:
>> >
>> >   1- unpack the tarball
>> >   2- create the repo and commit the unpacked files
>> >   3- pull the patches from their repo
>> >   4- apply the patches ("hg qpush -a")
>> >   5- build
>> 
>> [ The step 0 being "download the tarball".  ]
>> 
>> Hmm... ignoring the issue of Mercurial -vs- Git, the equivalent using
>> the VCS would be:
>> 
>>     0- clone from the remote repository to a local "bare" repository.
>>     1- clone from that local repository
>>     2- do nothing
>>     3- pull the patches from their repo
>>     4- apply the patches
>>     5- build
>
> Yeah, if all I were doing was applying static patches, there would be
> less benefit to using MQ.  But MQ helps with the tedium of managing a
> patch repo as I refine the patches.  (And I'm probably biased, since
> I've been using Mercurial for over 10 years, but I only started using
> Git when Emacs moved to it.)

Note that steps 3-5 are 100% unchanged.

> Sometime a few years ago I used a Mercurial extension to access a Git
> repo.  I had pretty much the same experience: it worked okay but was
> kinda slow.  I don't know if that extension is still available or
> maintained.

If the conversion to a different repository format is the problem, then
I guess passing through tar is not that bad of a deal, indeed (you can
get the same result by "git clone"ing and then committing the result to
an Hg repository, but the benefits are not as clear).


        Stefan

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 617 bytes --]

On 1/16/19 2:30 AM, Glenn Morris wrote:
> I see zero practical advantages to a switch to a "distribute everything"
> approach (which Emacs has never done, and nor when I check do eg tar,
> texinfo, coreutils); unless it will drastically simplify make-dist and
> avoid problems like the one fixed in 021f34b. If it does then I am all
> for it. :)

OK, proposed make-dist patch attached. This patch drastically simplifies 
the list of files in make-dist that needs to be maintained manually, by 
relying on Git to keep track of files under version control. This should 
help avoid problems like the one you mentioned.


[-- Attachment #2: 0001-Make-make-dist-more-automatic.txt --]
[-- Type: text/plain, Size: 13847 bytes --]

From 2325172f59faa4f3c1d41262ccf1ebd520d5b736 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 22 Jan 2019 13:52:24 -0800
Subject: [PATCH] Make make-dist more automatic
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Simplify make-dist maintenance by having it generate its
list of files more automatically.  Put the list of distributed
files into a file MANIFEST that can be used in the unusual
situations when you’re making a distribution without having
access to a Git repository.
* make-dist (top_level_ChangeLog): Now nonempty if the
distribution tarball will contain a ChangeLog, instead of
being nonempty when a ChangeLog is requested, Git is present
and a readable ChangeLog exists.  The new interpretation makes
the script a bit easier to follow.
(possibly_non_vc_files, info_files, mkdir_verbose)
(file_to_skip, MANIFEST_subdir_sed, tempsubdirs):
New variables.
(MANIFEST): Update and use this file, which now records what
files are distributed.
(top_level, subdir, files, file): Remove.
---
 make-dist | 346 ++++++++++++------------------------------------------
 1 file changed, 75 insertions(+), 271 deletions(-)

diff --git a/make-dist b/make-dist
index 20be62da1f..62e47b4d14 100755
--- a/make-dist
+++ b/make-dist
@@ -358,6 +358,50 @@ tempparent=
   $EMACS -batch -f batch-byte-recompile-directory lisp
 fi                              # $update = yes
 
+if [ "$changelog" = yes ] && [ -r .git ]; then
+  top_level_ChangeLog=ChangeLog
+else
+  top_level_ChangeLog=
+fi
+
+# Files to distribute that might not be under version control.
+# Don't distribute site-init.el, site-load.el, or default.el.
+possibly_non_vc_files="
+  $top_level_ChangeLog
+  MANIFEST aclocal.m4 configure
+  admin/charsets/jisx2131-filter
+  src/config.in src/dmpstruct.h src/emacs-module.h
+  src/fingerprint.c src/stamp-h.in
+"$(
+  find admin doc etc lisp \
+    \( -name '*.el' -o -name '*.elc' -o -name '*.map' -o -name '*.stamp' \
+       -o -name '*.texi' -o -name '*.tex' -o -name '*.txt' \) \
+    ! -name 'site-init*' ! -name 'site-load*' ! -name 'default*'
+) || exit
+
+if [ $with_info = yes ]; then
+  info_files="info/dir $(echo info/*.info)" || exit
+else
+  info_files=
+fi
+
+# If Git is in use update the file MANIFEST, which can substitute for
+# 'git ls-files' later (e.g., after extraction from a tarball).
+# Otherwise, rely on the existing MANIFEST, which should be maintained some
+# other way when adding or deleting a distributed file while not using Git.
+if [ $update = yes ] && [ -r .git ]; then
+  echo "Updating MANIFEST"
+  if [ $with_tests = yes ]; then
+    git ls-files >MANIFEST
+  else
+    git ls-files | grep -v '^test' >MANIFEST
+  fi || exit
+  printf '%s\n' $possibly_non_vc_files $info_files >>MANIFEST || exit
+  sort -u -o MANIFEST MANIFEST || exit
+fi
+
+<MANIFEST || exit
+
 echo "Creating staging directory: '${tempparent}'"
 
 mkdir ${tempparent} || exit
@@ -370,290 +414,52 @@ tempdir=
 fi
 
 echo "Creating top directory: '${tempdir}'"
-mkdir ${tempdir} || exit
+if [ $verbose = yes ] && (mkdir --verbose ${tempdir}) >/dev/null 2>&1; then
+  mkdir_verbose='mkdir --verbose'
+else
+  mkdir $tempdir || exit
+  mkdir_verbose=mkdir
+fi
+
+# file_to_skip is normally empty to link every file,
+# but it can be 'ChangeLog' if we do not want to link the
+# top-level ChangeLog.
+file_to_skip=
 
-top_level_ChangeLog=
 if [ "$changelog" = yes ]; then
   if test -r .git; then
     ## When making a release or pretest the ChangeLog should already
     ## have been created and edited as needed.  Don't ignore it.
-    if test -r ChangeLog; then
+    if [ -r ChangeLog ] && [ ! -L ChangeLog ]; then
       echo "Using existing top-level ChangeLog"
-      top_level_ChangeLog=ChangeLog
     else
       echo "Making top-level ChangeLog"
       make ChangeLog CHANGELOG=${tempdir}/ChangeLog || \
         { x=$?; echo "make ChangeLog FAILED (try --no-changelog?)" >&2; exit $x; }
+      file_to_skip=ChangeLog
     fi
   else
     echo "No repository, so omitting top-level ChangeLog"
   fi
 fi
 
-### We copy in the top-level files before creating the subdirectories in
-### hopes that this will make the top-level files appear first in the
-### tar file; this means that people can start reading the INSTALL and
-### README while the rest of the tar file is still unpacking.  Whoopee.
-echo "Making links to top-level files"
-top_level='
-  INSTALL README BUGS
-  ChangeLog.*[0-9] Makefile.in autogen.sh configure configure.ac
-  config.bat make-dist .dir-locals.el
-  aclocal.m4 CONTRIBUTE
-'
-ln $top_level $top_level_ChangeLog $tempdir || exit
-
 echo "Creating subdirectories"
-for subdir in site-lisp \
-	      leim leim/CXTERM-DIC leim/MISC-DIC leim/SKK-DIC \
-	      build-aux \
-	      src src/bitmaps lib lib-src oldXMenu lwlib \
-	      nt nt/inc nt/inc/sys nt/inc/arpa nt/inc/netinet nt/icons \
-	      `find etc lisp admin test -type d` \
-	      doc doc/emacs doc/misc doc/man doc/lispref doc/lispintro \
-	      info m4 modules msdos \
-	      nextstep nextstep/templates \
-	      nextstep/Cocoa nextstep/Cocoa/Emacs.base \
-	      nextstep/Cocoa/Emacs.base/Contents \
-	      nextstep/Cocoa/Emacs.base/Contents/Resources \
-	      nextstep/GNUstep \
-	      nextstep/GNUstep/Emacs.base \
-	      nextstep/GNUstep/Emacs.base/Resources
-do
-
-  if [ "$with_tests" != "yes" ]; then
-    case $subdir in
-        test*) continue ;;
-    esac
-  fi
-
-  ## site-lisp for in-place installs (?).
-  [ "$subdir" = "site-lisp" ] || [ -d "$subdir" ] || \
-      echo "WARNING: $subdir not found, making anyway"
-  [ "$verbose" = "yes" ] && echo "  ${tempdir}/${subdir}"
-  mkdir ${tempdir}/${subdir} || exit
-done
-
-echo "Making links to 'lisp' and its subdirectories"
-files=`find lisp \( -name '*.el' -o -name '*.elc' -o -name 'ChangeLog*' \
- -o -name 'README' \)` || exit
-
-### Don't distribute site-init.el, site-load.el, or default.el.
-for file in lisp/Makefile.in $files; do
-  case $file in
-    */site-init*|*/site-load*|*/default*) continue ;;
-  esac
-  ln $file $tempdir/$file || exit
-done
-
-echo "Making links to 'leim' and its subdirectories"
-(cd leim &&
- ln ChangeLog.*[0-9] README ../${tempdir}/leim &&
- ln CXTERM-DIC/README CXTERM-DIC/*.tit ../${tempdir}/leim/CXTERM-DIC &&
- ln SKK-DIC/README SKK-DIC/SKK-JISYO.L ../${tempdir}/leim/SKK-DIC &&
- ln MISC-DIC/README MISC-DIC/*.* ../${tempdir}/leim/MISC-DIC &&
- ln Makefile.in ../${tempdir}/leim/Makefile.in &&
- ln leim-ext.el ../${tempdir}/leim/leim-ext.el &&
-:) || exit
-
-## FIXME Can we not just use the "find -type f" method for this one?
-echo "Making links to 'build-aux'"
-(cd build-aux &&
- ln config.guess config.sub msys-to-w32 ../${tempdir}/build-aux &&
- ln gitlog-to-changelog gitlog-to-emacslog ../${tempdir}/build-aux &&
- ln install-sh move-if-change ../${tempdir}/build-aux &&
- ln update-copyright update-subdirs ../${tempdir}/build-aux &&
- ln dir_top make-info-dir ../${tempdir}/build-aux &&
-:) || exit
-
-echo "Making links to 'src'"
-### Don't distribute the configured versions of
-### config.in, paths.in, buildobj.h, or Makefile.in.
-(cd src &&
- ln [a-zA-Z]*.[chm] ../${tempdir}/src &&
- ln [a-zA-Z]*.in ../${tempdir}/src &&
- ln deps.mk dmpstruct.awk ../${tempdir}/src &&
- ln README ChangeLog.*[0-9] ../${tempdir}/src &&
- ln .gdbinit .dbxinit ../${tempdir}/src &&
- cd ../${tempdir}/src &&
- rm -f globals.h config.h epaths.h Makefile buildobj.h &&
-:) || exit
-
-echo "Making links to 'src/bitmaps'"
-(cd src/bitmaps &&
- ln README *.xbm ../../${tempdir}/src/bitmaps &&
-:) || exit
-
-echo "Making links to 'lib'"
-(cd lib &&
- ln [a-zA-Z_]*.[ch] ../${tempdir}/lib &&
- ln gnulib.mk.in Makefile.in ../${tempdir}/lib &&
- cd ../${tempdir}/lib &&
- script='/[*]/d; s/\.in\.h$/.h/' &&
- rm -f `ls *.in.h | sed "$script"` &&
-:) || exit
-
-echo "Making links to 'lib-src'"
-(cd lib-src &&
- ln [a-zA-Z]*.[ch] ../${tempdir}/lib-src &&
- ln ChangeLog.*[0-9] Makefile.in README ../${tempdir}/lib-src &&
- ln rcs2log ../${tempdir}/lib-src &&
-:) || exit
-
-echo "Making links to 'm4'"
-(cd m4 &&
- ln *.m4 ../${tempdir}/m4 &&
-:) || exit
-
-echo "Making links to 'modules'"
-(cd modules &&
- ln *.py ../${tempdir}/modules &&
-:) || exit
-
-echo "Making links to 'nt'"
-(cd nt &&
- ln emacs-x86.manifest emacs-x64.manifest ../${tempdir}/nt &&
- ln [a-z]*.bat [a-z]*.[ch] ../${tempdir}/nt &&
- ln *.in gnulib-cfg.mk ../${tempdir}/nt &&
- ln mingw-cfg.site epaths.nt INSTALL.W64 ../${tempdir}/nt &&
- ln ChangeLog.*[0-9] INSTALL README README.W32 ../${tempdir}/nt &&
-:) || exit
-
-echo "Making links to 'nt/inc' and its subdirectories"
-for f in `find nt/inc -type f -name '[a-z]*.h'`; do
-  ln $f $tempdir/$f || exit
-done
-
-echo "Making links to 'nt/icons'"
-(cd nt/icons &&
- ln README [a-z]*.ico ../../${tempdir}/nt/icons &&
- ln [a-z]*.cur ../../${tempdir}/nt/icons &&
-:) || exit
-
-echo "Making links to 'msdos'"
-(cd msdos &&
- ln ChangeLog.*[0-9] INSTALL README emacs.ico emacs.pif ../${tempdir}/msdos &&
- ln depfiles.bat inttypes.h ../${tempdir}/msdos &&
- ln mainmake.v2 sed*.inp ../${tempdir}/msdos &&
-:) || exit
-
-echo "Making links to 'nextstep'"
-(cd nextstep &&
- ln ChangeLog.*[0-9] README INSTALL Makefile.in ../${tempdir}/nextstep &&
-:) || exit
-
-echo "Making links to 'nextstep/templates'"
-(cd nextstep/templates &&
- ln Emacs.desktop.in Info-gnustep.plist.in Info.plist.in InfoPlist.strings.in \
-   ../../${tempdir}/nextstep/templates &&
-:) || exit
-
-echo "Making links to 'nextstep/Cocoa/Emacs.base/Contents'"
-(cd nextstep/Cocoa/Emacs.base/Contents &&
- ln PkgInfo ../../../../${tempdir}/nextstep/Cocoa/Emacs.base/Contents &&
-:) || exit
-
-echo "Making links to 'nextstep/Cocoa/Emacs.base/Contents/Resources'"
-(cd nextstep/Cocoa/Emacs.base/Contents/Resources &&
- ln Credits.html *.icns \
-   ../../../../../${tempdir}/nextstep/Cocoa/Emacs.base/Contents/Resources &&
-:) || exit
-
-echo "Making links to 'nextstep/GNUstep/Emacs.base/Resources'"
-(cd nextstep/GNUstep/Emacs.base/Resources &&
- ln README emacs.tiff \
-   ../../../../${tempdir}/nextstep/GNUstep/Emacs.base/Resources &&
-:) || exit
-
-echo "Making links to 'oldXMenu'"
-(cd oldXMenu &&
- ln *.[ch] *.in *.mk ../${tempdir}/oldXMenu &&
- ln README ChangeLog.*[0-9] ../${tempdir}/oldXMenu &&
-:) || exit
-
-echo "Making links to 'lwlib'"
-(cd lwlib &&
- ln *.[ch] *.in *.mk ../${tempdir}/lwlib &&
- ln README ChangeLog.*[0-9] ../${tempdir}/lwlib &&
-:) || exit
-
-## It is important to distribute admin/ because it contains sources
-## for generated lisp/international/uni-*.el files.
-echo "Making links to 'admin' and its subdirectories"
-for f in `find admin -type f`; do
-  case $f in
-    */Makefile) [ -f $f.in ] && continue ;;
-  esac
-  ln $f $tempdir/$f || exit
-done
-
-if [ "$with_tests" = "yes" ]; then
-  echo "Making links to 'test' and its subdirectories"
-  for f in `find test -type f ! -name '*.log' ! -name a.out \
-	      ! -name '*.so' ! -name '*.dll' ! -name '*.o'
-  `; do
-    case $f in
-        */Makefile) [ -f $f.in ] && continue ;;
-    esac
-    ln $f $tempdir/$f || exit
-  done
-fi
-
-echo "Making links to 'etc' and its subdirectories"
-for f in `find etc -type f`; do
-  case $f in
-    etc/DOC*|etc/*.pyc) continue ;;
-    ## Arguably we should not exclude *.ps.
-    etc/refcards/*.aux|etc/refcards/*.dvi|etc/refcards/*.log|etc/refcards/*.ps)
-      continue ;;
-  esac
-  ln $f $tempdir/$f || exit
-done
-
-if [ "$with_info" = "yes" ]; then
-  echo "Making links to 'info'"
-  ln `find info -type f -print` ${tempdir}/info || exit
-fi
+MANIFEST_subdir_sed='
+  $a\
+'$tempdir'/info\
+'$tempdir'/site-lisp
+  s,[^/]*$,,
+  s,/$,,
+  /^$/d
+  s,^,'$tempdir'/,
+'
+tempsubdirs=$(sed "$MANIFEST_subdir_sed" MANIFEST | sort -u)
+$mkdir_verbose -p $tempsubdirs || exit
 
-echo "Making links to 'doc/emacs'"
-(cd doc/emacs &&
- ln *.texi *.in ChangeLog.*[0-9] ../../${tempdir}/doc/emacs &&
-:) || exit
-
-echo "Making links to 'doc/misc'"
-(cd doc/misc &&
- ln *.texi *.tex *.in gnus-news.el ChangeLog.*[0-9] \
-   ../../${tempdir}/doc/misc &&
-:) || exit
-
-echo "Making links to 'doc/lispref'"
-(cd doc/lispref &&
- ln *.texi *.in README ChangeLog.*[0-9] ../../${tempdir}/doc/lispref &&
- ln spellfile ../../${tempdir}/doc/lispref &&
- ln two-volume.make two-volume-cross-refs.txt ../../${tempdir}/doc/lispref &&
-:) || exit
-
-echo "Making links to 'doc/lispintro'"
-(cd doc/lispintro &&
- ln *.texi *.in *.eps *.pdf ../../${tempdir}/doc/lispintro &&
- ln README ChangeLog.*[0-9] ../../${tempdir}/doc/lispintro &&
- cd ../../${tempdir}/doc/lispintro &&
-:) || exit
-
-echo "Making links to 'doc/man'"
-(cd doc/man &&
- ln *.*[0-9] *.in ../../${tempdir}/doc/man &&
- cd ../../${tempdir}/doc/man &&
- rm -f emacs.1 &&
-:) || exit
-
-### It would be nice if they could all be symlinks to top-level copy, but
-### you're not supposed to have any symlinks in distribution tar files.
-echo "Making sure copying notices are all copies of 'COPYING'"
-for subdir in . etc leim lib lib-src lisp lwlib msdos nt src; do
-  rm -f ${tempdir}/${subdir}/COPYING || exit
-  cp COPYING ${tempdir}/${subdir} || exit
-done
+echo "Making links to files"
+while read file; do
+  [ $file = "$file_to_skip" ] || ln $file $tempdir/$file || exit
+done <MANIFEST
 
 if [ "${newer}" ]; then
   printf '%s\n' "Removing files older than $newer"
@@ -664,10 +470,6 @@ files=
     -exec rm -f {} \; || exit
 fi
 
-## Don't distribute backups, autosaves, etc.
-echo "Removing unwanted files"
-find ${tempdir} \( -name '*~' -o -name '#*#' -o -name '.*ignore' -o -name '=*' -o -name 'TAGS' \) -exec rm -f {} \; || exit
-
 if [ "${make_tar}" = yes ]; then
   echo "Looking for $default_gzip"
   found=0
@@ -715,4 +517,6 @@ files=
   rm -rf ${tempparent}
 fi
 
-### make-dist ends here
+# Local Variables:
+# sh-basic-offset: 2
+# End:
-- 
2.20.1

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 22 Jan 2019 13:58:49 -0800
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> On 1/16/19 2:30 AM, Glenn Morris wrote:
> > I see zero practical advantages to a switch to a "distribute everything"
> > approach (which Emacs has never done, and nor when I check do eg tar,
> > texinfo, coreutils); unless it will drastically simplify make-dist and
> > avoid problems like the one fixed in 021f34b. If it does then I am all
> > for it. :)
> 
> OK, proposed make-dist patch attached. This patch drastically simplifies 
> the list of files in make-dist that needs to be maintained manually, by 
> relying on Git to keep track of files under version control. This should 
> help avoid problems like the one you mentioned.

I think you forgot a few files, like PDF refcards etc., which are
produced by the build, but included in the tarball.

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Paul Eggert]

On 1/23/19 8:14 AM, Eli Zaretskii wrote:
> I think you forgot a few files, like PDF refcards etc., which are
> produced by the build, but included in the tarball.

No problem there, as the PDF refcards are directly version-controlled.

I perhaps should have mentioned that I tested the proposed make-dist and 
the only files that it omits are files that it should omit. In my test, 
hee is a list of files that current master make-dist includes but the 
proposed make-dist omits:

* admin/CPP-DEFINES.orig - this is a file left over from 'patch' that 
the current make-dist mistakely includes.

* src/t.c - this is a little test file in my src directory that the 
current make-dist mistakenly includes

* src/temacs.in - this is a built executable in my src directory that 
the current make-dist mistakenly includes (obviously a bug).

Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out]

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 23 Jan 2019 09:52:54 -0800
> Cc: rgm@gnu.org, emacs-devel@gnu.org
> 
> I perhaps should have mentioned that I tested the proposed make-dist

I thought you were asking for a review nonetheless.