Re: Windows 28.1 install/zip has el newer than elc for some files?

[Corwin Brust]

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