From: Corwin Brust <corwin@bru.st>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: Windows 28.1 install/zip has el newer than elc for some files?
Date: Thu, 21 Apr 2022 10:55:35 -0500 [thread overview]
Message-ID: <CAJf-WoT8powvmYWH3j4rWDCZSMXeypfbJD-xb276wmRuQv_k3Q@mail.gmail.com> (raw)
In-Reply-To: <83mtggtgkw.fsf@gnu.org>
On Wed, Apr 20, 2022 at 1:27 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Corwin, I don't understand why the time stamps of the *.el files in
> the binary distribution don't match those in the source tarball on the
> GNU FTP site. Do your build procedures somehow modify the time stamps
> of source files? If so, can you spot which part(s) of the build
> procedures does that and fix those parts?
In short, I have no idea how the modification dates are being changed.
It seems to me that they aren't:
corwi@Avalon MINGW64 /d/emacs-build
$ unzip -lv install/upload/emacs-28.1.zip | grep xwidget.el
28927 Defl:X 7669 74% 2022-03-11 01:04 8d0d1e4b
emacs-28.1/share/emacs/28.1/lisp/xwidget.el
25110 Defl:X 7180 71% 2022-04-03 07:16 3d3a8c8c
emacs-28.1/share/emacs/28.1/lisp/xwidget.elc
corwi@Avalon MINGW64 /d/emacs-build
$ ls -l emacs-28.1/lisp | grep xwidget
-rw-r--r-- 1 corwi corwi 28927 Mar 11 01:04 xwidget.el
-rw-r--r-- 1 corwi corwi 25110 Apr 3 07:16 xwidget.elc
corwi@Avalon MINGW64 /d/emacs-build
$ tar -t -v --full-time -f ~/emacs-upload/emacs-28.1.tar.xz | grep xwidget.el
-rw-r--r-- 0/0 28927 2022-03-11 01:04:22 emacs-28.1/lisp/xwidget.el
-rw-r--r-- 0/0 25110 2022-04-03 07:16:59 emacs-28.1/lisp/xwidget.elc
>
> Or maybe this happens because you build from Git and not from the
> tarball? In that case, this is a potential problem I already
> indicated, and I think you should use the tarball. One reason is that
> the tarball includes some files specifically produced for a release
> that the Git repository doesn't have, for example the PDF files in
> etc/refcards. Another potential issue is that building from Git means
> you produce your own *.elc files, whereas the tarball already includes
> them, and you probably produce them on Windows. That is something we
> should avoid, I think.
You will see from the below that I am using the source tarball for the
new versions I've recently posted however I did find that I need to
run make clean or otherwise no ELN files are produced (even when I
tried specifying NATIVE_FULL_AOT=1 to make). I'm assuming this need
to make clean and then run autogen.sh isn't expected. Would it make
sense to create a bug report for this?
If there are other things I can try I'm happy to do so.
Here is the full set of commands I've used to make the set presently
uploaded. The referenced ~/emacs-upload/emacs-28.1.tar.xz was
downloaded from the GNU fpt site. I then created /d/emacs-upload and
ran this sequence, all within a MinGW 64 bash shell.
tar -xf ~/emacs-upload/emacs-28.1.tar.xz
cd emacs-28.1/
make clean
./autogen.sh
./configure --with-modules --without-dbus --with-native-compilation
--without-compress-install CFLAGS=-O2
rm -rf ../install/emacs-28.1
mkdir ../install/emacs-28.1
make install-strip -j 20 prefix=/d/emacs-build/install/emacs-28.1
echo $?
cp admin/nt/dist-build/emacs.nsi ../install/
cd ../install/
zip -r -9 emacs-28.1-no-deps.zip emacs-28.1/*
unzip -d emacs-28.1/bin ~/emacs-build/deps/emacs-28-deps.zip
zip -r -9 emacs-28.1.zip emacs-28.1/*
makensis -v4 -DEMACS_VERSION=28.1 -DVERSION_BRANCH=28.1
-DOUT_VERSION=28.1 emacs.nsi
mkdir upload
mv *.zip *.exe upload
cd upload
for f in * ; do gpg --batch --yes -b $f ; done
for f in *.{zip,exe} ; do cp
/d/projects/emacs-build/new-hotness/emacs-28.directive $f.directive;
perl -pi -e "s/__FILE__/$f/" $f.directive ; done
for f in emacs-28.1*{zip,exe} ; do gpg --batch --yes --clearsign
$f.directive ; done
ls -altr
next prev parent reply other threads:[~2022-04-21 15:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 10:20 Windows 28.1 install/zip has el newer than elc for some files? Joel Reicher
2022-04-19 21:14 ` Corwin Brust
2022-04-19 23:20 ` Corwin Brust
2022-04-20 2:33 ` Corwin Brust
2022-04-20 3:15 ` Joel Reicher
2022-04-20 6:27 ` Eli Zaretskii
2022-04-21 15:55 ` Corwin Brust [this message]
2022-04-21 16:03 ` Eli Zaretskii
2022-04-21 16:08 ` Corwin Brust
2022-04-21 18:34 ` Eli Zaretskii
2022-04-21 16:11 ` Corwin Brust
2022-04-21 17:06 ` Corwin Brust
2022-04-22 6:02 ` Corwin Brust
2022-04-21 18:36 ` Eli Zaretskii
2022-04-22 1:20 ` Corwin Brust
2022-04-22 5:26 ` Eli Zaretskii
2022-04-22 5:53 ` Corwin Brust
2022-04-22 6:18 ` Corwin Brust
2022-04-22 6:45 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJf-WoT8powvmYWH3j4rWDCZSMXeypfbJD-xb276wmRuQv_k3Q@mail.gmail.com \
--to=corwin@bru.st \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.