[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MinGW Sources, was: Windows Binaries Release
From: |
Phillip Lord |
Subject: |
Re: MinGW Sources, was: Windows Binaries Release |
Date: |
Mon, 08 Nov 2021 22:27:22 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) |
"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
- Re: Windows Binaries Release: was The emacs-28 release branch, H. Dieter Wilhelm, 2021/11/01
- Re: Windows Binaries Release: was The emacs-28 release branch, Óscar Fuentes, 2021/11/01
- Eshell requires execute permission on Win10, was Re: Windows Binaries Release: was The emacs-28 release branch, H. Dieter Wilhelm, 2021/11/02
- Re: Eshell requires execute permission on Win10, was Re: Windows Binaries Release: was The emacs-28 release branch, Óscar Fuentes, 2021/11/02
- MinGW Sources, was: Windows Binaries Release, H. Dieter Wilhelm, 2021/11/02
- Re: MinGW Sources, was: Windows Binaries Release, Óscar Fuentes, 2021/11/02
- Re: MinGW Sources, was: Windows Binaries Release, H. Dieter Wilhelm, 2021/11/04
- Re: MinGW Sources, was: Windows Binaries Release,
Phillip Lord <=
- Re: MinGW Sources, was: Windows Binaries Release, Eli Zaretskii, 2021/11/09
- Re: MinGW Sources, was: Windows Binaries Release, Phillip Lord, 2021/11/09
Re: Windows Binaries Release: was The emacs-28 release branch, Phillip Lord, 2021/11/02