Re: MinGW Sources, was: Windows Binaries Release

[Phillip Lord <phillip.lord@russet.org.uk>]

"H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:
>>
>>> in d:/Emacs/emacs-28/admin/nt/dist-build/build-dep-zips.py there is 
>>>
>>>   SRC_REPO="https://sourceforge.net/projects/msys2/files/REPOS/MINGW/Sources".
>>>
>>> But it seems that the Sources folder vanished (for the moment?)!  Do
>>> you, or anybody else, know where else sources of MinGW are?
>>
>> Try
>>
>> https://repo.msys2.org/mingw/sources/
>
> Yes, thank you!
>
> modified   admin/nt/dist-build/build-dep-zips.py
> @@ -121,7 +121,8 @@ def ntldd_munge(out):
>  
>  ## Currently no packages seem to require this!
>  ARCH_PKGS=[]
> -SRC_REPO="https://sourceforge.net/projects/msys2/files/REPOS/MINGW/Sources"
> +## SRC_REPO="https://sourceforge.net/projects/msys2/files/REPOS/MINGW/Sources"
> +SRC_REPO="https://repo.msys2.org/mingw/sources"
>  
>  
>  def immediate_deps(pkg):
> @@ -167,7 +168,7 @@ def download_source(tarball):
>      if not os.path.exists("../emacs-src-cache/{}".format(tarball)):
>          print("Downloading {}...".format(tarball))
>          check_output_maybe(
> -            "wget -a ../download.log -O ../emacs-src-cache/{} {}/{}/download"
> +            "wget -a ../download.log -O ../emacs-src-cache/{} {}/{}"
>              .format(tarball, SRC_REPO, tarball),
>              shell=True
>          )
>

Do you have access to the Emacs git repo? Can you add this?



>> That directory contains tarballs with the exact sources used to build
>> their respective binary packages.
>
> Adjusted build-dep-zips.py and had to install some missing MSYS2
> packages but now the script builds dpendencies.  And the other script
> seems to build Emacs.  But I'm still unsecure about the naming.
> E.g. why are snapshots of Emacs aren't named with the date but just
> "emacs-29.0.50-snapshot"?
>
> ~/
> |- emacs-build/
> |	|- git/
> |	|  |- emacs-$branch ?
> |	|  |- master/ (for snapshots) -> emacs-29.0.50-snapshot
> |	|  |- emacs-$version
> |	|- deps/
> |	|  |- libXpm/
> |	|  |  |- libXpm-noX4.dll (cp from /bin, manually)
> |       |  |- src-emacs (sources from dep py script)  
> |       |  |- src-emacs-cache (from dep py script)  
> |       |  |- x86_64 (DLLs from dep.py script)  
> |	|- build/
> |	|  |- $version
> |	|- install/ (from script)
> |	   |- emacs-29.0.50-snapshot/
> |             |- Emacs' tree
> |- emacs-upload/




Right. When a release happens, we create a new worktree from the
tag. So, we currently have the emacs-28 release branch which will we
eventually worktree to give emacs-28.1.

The problem is that because we are making a build from a completely
unbuilt branch at this point we do a de novo build of everything,
including all the el->elc byte compilation (and some elc->eln for the
preloads). It takes time -- about 4-5 hours for a 64 and 32 bit build
(IIRC, we have ditched the i686 build now, but still).

That's fine for a release. But for snapshots, it a lot. So we might want
to build snapshots from the emacs-28 or master branch. For snapshots,
the risk of an non-clean, incremental build is perfectly justified, so
we do not make a new branch. As the elc files go into the source tree
(even for an "out-of-source" build) they will still be there; again,
IIRC, the scripts do not delete the "build" directory so even the C is
build incrementally; we do need to delete the install directory, because
building the zip file with dependencies, including the installer
version, alters the install tree, so make that clean every time -- not a
biggie as it's just a copy and takes very little time.

All of this, of course, is dependent on building shapshots. I did that
well for a while, but over the recent past, it has happened very, very
rarely. Be a different matter, perhaps, if it were fully automated, but
I never quite got there. Snapshots are not essential, though, and I have
no idea how many people were actually using them.

Cheers

Phil