Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: > That works as well, indeed. There are many ways to skin this cat. Meow! > Ah, OK. Not sure why you find it ugly, but there's no accounting > for taste. I find it a bit unnatural to load a file containing the autoloads by hand. But maybe I have to change my mental model on that. > I think the patch below does that. > > > diff --git a/GNUmakefile b/GNUmakefile > index b5cec4822e..fbf653ab09 100644 > --- a/GNUmakefile > +++ b/GNUmakefile > @@ -17,7 +17,8 @@ > # latex: prtightpage.def > # latex: prtracingall.def > > autoloads: > - $(EMACS) -f loaddefs-generate-batch loaddefs.el . > + $(EMACS) --eval \ > + "(loaddefs-generate \".\" \"auctex-autoloads.el\" \ > +nil \"(add-to-list 'load-path\ > + (directory-file-name \ > +(file-name-directory load-file-name)))\")" Thanks, it works. The only issue we have to solve next is how to cater for Emacs<29 which don't have `loaddefs-generate' (we have a solution for that in the old Makefile; we have to check if have to reactivate that part.) Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
>> I use it with `emacs -Q ...` when I want to try and isolate a problem.
>
> Thanks for the hint. My approach to that for package `foo' until now
> was:
>
> (progn
> (package-initialize t)
> (package-activate 'foo))
That works as well, indeed. There are many ways to skin this cat.
[ In my case, most packages are installed in a non-standard directory,
so I'd first have to set `package-user-dir`, and also I find it
less convenient to use `--eval` than `-l`. ]
> By ugly I meant (load "loaddefs.el").
Ah, OK. Not sure why you find it ugly, but there's no accounting
for taste.
> • Get auctex-autoloads.el instead of loaddefs.el, and
I think this is just a matter of changing the file name
in GNUmakefile's `autoloads` target.
> • Put the addition to `load-path' in that file, so the forms above
> turn into (load "~/Repos/el/auctex/auctex-autoloads" nil t t) as
> well?
I think the patch below does that.
Stefan
diff --git a/GNUmakefile b/GNUmakefile
index b5cec4822e..fbf653ab09 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -17,7 +17,8 @@
# latex: prtightpage.def
# latex: prtracingall.def
-EMACS=emacs --batch -q -no-site-file -no-init-file -l lpath.el
+EMACSBIN=emacs
+EMACS=$(EMACSBIN) --batch -q -no-site-file -no-init-file -l lpath.el
MAKEINFO=makeinfo
INSTALL_INFO=install-info
PERL=perl
@@ -44,7 +45,11 @@ all: $(ALL_GENERATED_FILES) compile autoloads
compile: $(patsubst %.el,%.elc,$(wildcard *.el style/*.el))
autoloads:
- $(EMACS) -f loaddefs-generate-batch loaddefs.el .
+ $(EMACS) --eval \
+ "(loaddefs-generate \".\" \"auctex-autoloads.el\" \
+nil \"(add-to-list 'load-path \
+ (directory-file-name \
+(file-name-directory load-file-name)))\")"
%.elc: %.el
$(EMACS) -f batch-byte-compile $<
@@ -74,18 +79,16 @@ README: doc/intro.texi doc/preview-readme.texi doc/macros.texi
# Commands copied from autogen.sh and doc/Makefile.in.
IGNORED:=$(shell rm -f ChangeLog && ./build-aux/gitlog-to-auctexlog && cat ChangeLog.1 >> ChangeLog)
# Committer date of HEAD.
-AUCTEXDATE:=$(shell git log -n1 --pretty=tformat:"%ci" \
- | sed -nre 's/ /_/p' | sed -nre 's/ .*//p')
+AUCTEXDATE:=$(shell (git log -n1 --pretty=tformat:"%ci" 2>/dev/null \
+ || date +"%Y-%m-%d %T") \
+| sed -re 's/ /_/' -e 's/ .*//')
# Extract the version number from the diff line "+;; Version: 14.0.4" of
# the commit HEAD which is only filled when we did a release in the last
# commit.
-THISVERSION:=$(shell git show HEAD -- auctex.el \
+THISVERSION:=$(shell git show HEAD -- auctex.el 2>/dev/null \
| sed -nre 's/[+];; Version: ([0-9]+.[0-9]+.[0-9]+)/\1/p')
-# Extract the last version number from the previous change to auctex.el,
-# i.e., only look at commits starting at HEAD~1.
-LASTVERSION:=$(shell git log HEAD~1 -p --first-parent -- auctex.el \
- | grep "+;; Version: " \
- | sed -nre 's/[+];; Version: ([0-9]+.[0-9]+.[0-9]+)/\1/p;q')
+# Extract the last released version number from `auctex.el`.
+LASTVERSION:=$(shell sed -nre '/Version:/{s/;; Version: ([0-9]+.[0-9]+.[0-9]+)/\1/p;q}' auctex.el)
AUCTEXVERSION:=$(if $(THISVERSION),$(THISVERSION),$(LASTVERSION).$(AUCTEXDATE))
tex-site.el: tex-site.el.in
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: > I use it with `emacs -Q ...` when I want to try and isolate a problem. Thanks for the hint. My approach to that for package `foo' until now was: (progn (package-initialize t) (package-activate 'foo)) > Indeed, usually `package-activate(-all)` performs those `load`s for the user. > I was just pointing out that there's a pre-existing and very similar > "convention" and that convention is slightly simpler for the users, so > if it's not too cumbersome it might be worth following that convention > (it's not very important, tho, so it's really up to the maintainers). I think we're on the same page, but I wasn't clear: The one-liner you sent is more appealing to me than what we have on the table now: (add-to-list 'load-path "~/Repos/el/auctex") (load "~/Repos/el/auctex/loaddefs.el" nil t t) By ugly I meant (load "loaddefs.el"). So my question was that for the scenario "Start AUCTeX out of Git repo and not installed as an ELPA package", if you have a pointer how to: • Get auctex-autoloads.el instead of loaddefs.el, and • Put the addition to `load-path' in that file, so the forms above turn into (load "~/Repos/el/auctex/auctex-autoloads" nil t t) as well? I hope I could explain it better this time. Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
>> Side note: an AUCTeX installed with `package.el` behaves very similarly >> except the autoloads file is called `auctex-autoloads.el` instead of >> `loaddefs.el` and that this file takes care of the `add-to-list`, so >> users just need to >> >> (load "~/Repos/el/auctex/auctex-autoloads") > > Thanks, but in which scenario do users have to use the form above? I use it with `emacs -Q ...` when I want to try and isolate a problem. > I thought when AUCTeX is installed via package.el, say with regular > updates or `package-install-from-archive', `package-initialize' and some > such would do the job. Indeed, usually `package-activate(-all)` performs those `load`s for the user. I was just pointing out that there's a pre-existing and very similar "convention" and that convention is slightly simpler for the users, so if it's not too cumbersome it might be worth following that convention (it's not very important, tho, so it's really up to the maintainers). > Side question: Is it possible to achieve something similar for the setup > above, i.e., running AUCTeX directly from the clone? This looks really > ugly to me: > > (load "~/Repos/el/auctex/loaddefs.el" nil t t) Not sure what you mean by "similar" since what you here describe as ugly is almost identical. I think I'm misunderstanding something. Stefan
Re: Making AUCTeX ELPA releases from the master branch
>>> "AE" == Arash Esbati writes: > Hi Tassilo, > Tassilo Horn writes: > Many thanks for working on this (and to Stefan as well). >> So basically, we should decide now if we switch to going ELPA-only in >> which case we'd not use master anymore but develop directly in main. >> (I'd be in favour of it, obviously.) >> >> We could also keep master as our development branch and still use the >> new "main" branch (which I would probably rename to "elpa" in that case) >> for elpa and turn on auto-sync. It would be a bit less automatic: we'd >> need to keep merging from master to the "main" / "elpa" regularly and >> increment the Version manually for releases. But it's still better than >> the status quo (less committed generated files; better Version >> determination). > I was thinking about this too and my vote is to go with option 2 (i.e., > not your favorite ;-). Given the problem I just encountered and reported I would like to support that vote: compiling and testing from the current master seems much more flexible and general. (but I have very little say on these matters, of course, but it would be sad if I can't test emacs without a lot of hassle) -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. smime.p7s Description: S/MIME cryptographic signature
[can't compile the main branch] (was: Making AUCTeX ELPA releases from the master branch)
>>> "TH" == Tassilo Horn writes: > Yes, it's only "make" now. > Am Di, 23. Apr 2024, um 20:56, schrieb Arash Esbati: >> Tassilo Horn writes: >> >>> I think we need to adapt our instructions. To run straight from the >>> clone, this seems to work fine: >>> >>> (add-to-list 'load-path "~/Repos/el/auctex") >>> (load "~/Repos/el/auctex/loaddefs.el" nil t t) >> >> Thanks, this does the job. Yes, we will have to adapt our instructions: >> the way I see it the whole machinery around ./configure, make, and make >> install will be gone, right? I found an additional problem. I pulled and switched to the main branch (I am using mercurial and the hg-git plugin/converter/extension) Then I run Make clean And make And I obtain fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git (cd doc; makeinfo -D rawfile --no-headers intro.texi --output -) >README (cd doc; makeinfo -D rawfile --no-headers preview-readme.texi --output -) >> README sed -e 's|@lisppackagelispdir@|(file-name-directory load-file-name)|'\ -e 's|@lisppackagedatadir@|(file-name-directory load-file-name)|'\ -e 's|@lispautodir@|(if (file-writable-p "/usr/local/var/auctex") "/usr/local/var/auctex" "~/.emacs.d/auctex")|'\ -e 's|@AUCTEXVERSION@|.|'\ -e 's|@AUCTEXDATE@||'\ tex-site.el.in >tex-site.el make: *** No rule to make target 'ChangeLog', needed by 'doc/version.texi'. Stop. Now why on earth should I have a git parent directory or directories? There is also no configure option more, since I have various emacs version installed (the one Ubuntu ships, the one or two I have compiled from master (and which end up in /opt/emacs29 or /opt/emacs30) So I have to to edit the makefile manually? But the missing .git directory message seems serious So I can't test anymore main/master I also find the solution of deleting the «make install option» hm inconvenient. Reason. 1. I pull, make (and would to install) 2. I would like to do some experiments (say starting a new style file) but now I am editing files of a repository I also use for my daily work. That does sound a bit dangerous. Can't you leave the make install option please. Regards Uwe -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. smime.p7s Description: S/MIME cryptographic signature
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: >> I think we need to adapt our instructions. To run straight from the >> clone, this seems to work fine: >> >> (add-to-list 'load-path "~/Repos/el/auctex") >> (load "~/Repos/el/auctex/loaddefs.el" nil t t) > > Side note: an AUCTeX installed with `package.el` behaves very similarly > except the autoloads file is called `auctex-autoloads.el` instead of > `loaddefs.el` and that this file takes care of the `add-to-list`, so > users just need to > > (load "~/Repos/el/auctex/auctex-autoloads") Thanks, but in which scenario do users have to use the form above? I thought when AUCTeX is installed via package.el, say with regular updates or `package-install-from-archive', `package-initialize' and some such would do the job. Or am I missing something? Side question: Is it possible to achieve something similar for the setup above, i.e., running AUCTeX directly from the clone? This looks really ugly to me: (load "~/Repos/el/auctex/loaddefs.el" nil t t) Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
Yes, it's only "make" now. Am Di, 23. Apr 2024, um 20:56, schrieb Arash Esbati: > Tassilo Horn writes: > >> I think we need to adapt our instructions. To run straight from the >> clone, this seems to work fine: >> >> (add-to-list 'load-path "~/Repos/el/auctex") >> (load "~/Repos/el/auctex/loaddefs.el" nil t t) > > Thanks, this does the job. Yes, we will have to adapt our instructions: > the way I see it the whole machinery around ./configure, make, and make > install will be gone, right? > > Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
Tassilo Horn writes: > I think we need to adapt our instructions. To run straight from the > clone, this seems to work fine: > > (add-to-list 'load-path "~/Repos/el/auctex") > (load "~/Repos/el/auctex/loaddefs.el" nil t t) Thanks, this does the job. Yes, we will have to adapt our instructions: the way I see it the whole machinery around ./configure, make, and make install will be gone, right? Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
> I think we need to adapt our instructions. To run straight from the > clone, this seems to work fine: > > (add-to-list 'load-path "~/Repos/el/auctex") > (load "~/Repos/el/auctex/loaddefs.el" nil t t) Side note: an AUCTeX installed with `package.el` behaves very similarly except the autoloads file is called `auctex-autoloads.el` instead of `loaddefs.el` and that this file takes care of the `add-to-list`, so users just need to (load "~/Repos/el/auctex/auctex-autoloads") - Stefan
Re: Making AUCTeX ELPA releases from the master branch
Arash Esbati writes: Hi Arash, > Thanks. I see an issue. I did: > > • $ git clone https://git.savannah.gnu.org/git/auctex.git auctex-elpa > • $ cd auctex-elpa > • $ git switch main > • $ make -j8 > • $ emacs -Q > • eval'ed in scratch: > (load "~/path/to/auctex-elpa/auctex.el" nil t t) > (load "~/path/to/auctex-elpa/preview.el" nil t t) I think we need to adapt our instructions. To run straight from the clone, this seems to work fine: (add-to-list 'load-path "~/Repos/el/auctex") (load "~/Repos/el/auctex/loaddefs.el" nil t t) loaddefs.el is the new autoloads file containing all autoloads of the whole project. Formerly, there was preview-latex.el with the preview.el autoloads and auto-loads.el with the autoloads of the remainder of AUCTeX. Bye, Tassilo
Re: Making AUCTeX ELPA releases from the master branch
Tassilo Horn writes:
> Ok, I've adjusted the elpa recipe and merged from master to main. So
> hopefully there will be some new devel package anytime soon at
>
> https://elpa.gnu.org/devel/auctex.html
>
> If that works fine, we can bump the Version in auctex.el and do a
> regular ELPA release.
Thanks. I see an issue. I did:
• $ git clone https://git.savannah.gnu.org/git/auctex.git auctex-elpa
• $ cd auctex-elpa
• $ git switch main
• $ make -j8
• $ emacs -Q
• eval'ed in scratch:
(load "~/path/to/auctex-elpa/auctex.el" nil t t)
(load "~/path/to/auctex-elpa/preview.el" nil t t)
• C-x C-f path/to/auctex-elpa/circ.tex RET throws:
File mode specification error: (void-function font-latex-setup)
Backtrace says:
--8<---cut here---start->8---
Debugger entered--Lisp error: (void-function font-latex-setup)
font-latex-setup()
TeX-mode()
LaTeX-mode()
TeX-tex-mode()
set-auto-mode-0(tex-mode nil)
set-auto-mode--apply-alist((("\\.hva\\'" . LaTeX-mode)
("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" .
elisp-byte-code-mode) ("\\.zst\\'" nil jka-compr) ("\\.dz\\'" nil jka-compr)
("\\.xz\\'" nil jka-compr) ("\\.lzma\\'" nil jka-compr) ("\\.lz\\'" nil
jka-compr) ("\\.g?z\\'" nil jka-compr) ("\\.bz2\\'" nil jka-compr) ("\\.Z\\'"
nil jka-compr) ("\\.vr[hi]?\\'" . vera-mode)
("\\(?:\\.\\(?:rbw?\\|ru\\|rake\\|thor\\|axlsx\\|jbuilder\\|rabl\\|gemspec\\|podspec\\)\\|/\\(?:Gem\\|Rake\\|Cap\\|Thor\\|Puppet\\|Berks\\|Brew\\|Fast\\|Vagrant\\|Guard\\|Pod\\)file\\)\\'"
. ruby-mode) ("\\.re?st\\'" . rst-mode) ("/\\(?:Pipfile\\|\\.?flake8\\)\\'" .
conf-mode) ("\\.py[iw]?\\'" . python-mode) ("\\.m\\'" . octave-maybe-mode)
("\\.less\\'" . less-css-mode) ("\\.scss\\'" . scss-mode) ("\\.cs\\'" .
csharp-mode) ("\\.awk\\'" . awk-mode)
("\\.\\(u?lpc\\|pike\\|pmod\\(\\.in\\)?\\)\\'" . pike-mode) ("\\.idl\\'" .
idl-mode) ("\\.java\\'" . java-mode) ("\\.m\\'" . objc-mode) ("\\.ii\\'" .
c++-mode) ("\\.i\\'" . c-mode) ("\\.lex\\'" . c-mode) ("\\.y\\(acc\\)?\\'" .
c-mode) ("\\.h\\'" . c-or-c++-mode) ("\\.c\\'" . c-mode)
("\\.\\(CC?\\|HH?\\)\\'" . c++-mode) ("\\.[ch]\\(pp\\|xx\\|\\+\\+\\)\\'" .
c++-mode) ("\\.\\(cc\\|hh\\)\\'" . c++-mode) ("\\.\\(bat\\|cmd\\)\\'" .
bat-mode) ("\\.[sx]?html?\\(\\.[a-zA-Z_]+\\)?\\'" . mhtml-mode) ("\\.svgz?\\'"
. image-mode) ("\\.svgz?\\'" . xml-mode) ("\\.x[bp]m\\'" . image-mode)
("\\.x[bp]m\\'" . c-mode) ("\\.p[bpgn]m\\'" . image-mode) ("\\.tiff?\\'" .
image-mode) ("\\.gif\\'" . image-mode) ("\\.png\\'" . image-mode)
("\\.jpe?g\\'" . image-mode) ("\\.webp\\'" . image-mode) ("\\.te?xt\\'" .
text-mode) ("\\.[tT]e[xX]\\'" . tex-mode) ("\\.ins\\'" . tex-mode) ("\\.ltx\\'"
. latex-mode) ...) nil nil)
set-auto-mode()
normal-mode(t)
after-find-file(nil t)
find-file-noselect-1(# "~/path/to/auctex-elpa/circ.tex" nil
nil "~/path/to/auctex-elpa/circ.tex" (21398298 16777231))
find-file-noselect("~/path/to/auctex-elpa/circ.tex" nil nil t)
find-file("~/path/to/auctex-elpa/circ.tex" t)
funcall-interactively(find-file "~/path/to/auctex-elpa/circ.tex" t)
command-execute(find-file)
--8<---cut here---end--->8---
Am I missing something?
Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
Arash Esbati writes: >> So, those few users installing from GNU-devel ELPA are probably ready >> and willing (if not eager) to try buggy software (that's what >> GNU-devel is for). Especially since fixes are also made available >> more promptly. > > Thanks. With this original intent of GNU-devel ELPA, let's go that > route and skip AUCTeX master. Ok, I've adjusted the elpa recipe and merged from master to main. So hopefully there will be some new devel package anytime soon at https://elpa.gnu.org/devel/auctex.html If that works fine, we can bump the Version in auctex.el and do a regular ELPA release. Crossing fingers, Tassilo
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes:
>> Stefan, how would I make the switch on elpa? The package recipe I've
>> tested is this
>>
>> (auctex :url "https://git.savannah.gnu.org/git/auctex.git;
>> :branch "main"
>> :news "NEWS.org"
>> :make "elpa"
>> :doc ("doc/auctex.texi" "doc/preview-latex.texi"))
>>
>> Does pushing the new recipe in elpa-packages suffice?
>
> Yes (tho we use a different indentation (for which there's no
> auto-indent rules )).
Ok, pushed with corrected indentation.
Thanks,
Tassilo
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: > FWIW, while we don't have good statistics to confirm it, I believe that > very few users routinely install packages from GNU-devel: contrary to > Melpa where the system is setup to encourage the use of Melpa over > Melpa-stable, the GNU ELPA archive is setup so as to encourage the use > of GNU ELPA over GNU-devel ELPA. > > So, those few users installing from GNU-devel ELPA are probably ready > and willing (if not eager) to try buggy software (that's what GNU-devel is > for). > Especially since fixes are also made available more promptly. Thanks. With this original intent of GNU-devel ELPA, let's go that route and skip AUCTeX master. Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
> I was thinking about this too and my vote is to go with option 2 (i.e., > not your favorite ;-). I think it would make sense to have a sort of > "staging area" where we can install code which might break or have other > problems. Syncing it directly to ELPA-DEVEL and letting people install > it might end in too much trouble for the brave users. FWIW, while we don't have good statistics to confirm it, I believe that very few users routinely install packages from GNU-devel: contrary to Melpa where the system is setup to encourage the use of Melpa over Melpa-stable, the GNU ELPA archive is setup so as to encourage the use of GNU ELPA over GNU-devel ELPA. So, those few users installing from GNU-devel ELPA are probably ready and willing (if not eager) to try buggy software (that's what GNU-devel is for). Especially since fixes are also made available more promptly. Stefan
Re: Making AUCTeX ELPA releases from the master branch
Hi Tassilo, Tassilo Horn writes: > I've created a "main" branch (split off externals/auctex) and adjusted > it such that it should be buildable on elpa and the mere act of changing > the Version number in auctex.el in a commit would trigger a new ELPA > release. And every other commit would at least trigger a new release on > ELPA-devel. Many thanks for working on this (and to Stefan as well). > So basically, we should decide now if we switch to going ELPA-only in > which case we'd not use master anymore but develop directly in main. > (I'd be in favour of it, obviously.) > > We could also keep master as our development branch and still use the > new "main" branch (which I would probably rename to "elpa" in that case) > for elpa and turn on auto-sync. It would be a bit less automatic: we'd > need to keep merging from master to the "main" / "elpa" regularly and > increment the Version manually for releases. But it's still better than > the status quo (less committed generated files; better Version > determination). I was thinking about this too and my vote is to go with option 2 (i.e., not your favorite ;-). I think it would make sense to have a sort of "staging area" where we can install code which might break or have other problems. Syncing it directly to ELPA-DEVEL and letting people install it might end in too much trouble for the brave users. Merging into "branch-name-tbd" shouldn't be a big deal then, I can do it, if we need a volunteer. And yes, it will be much better than what we have right now. Reg. dropping tarball-release and for me to recap: We, or more precisely Mosè doesn't make any releases and distro-packagers should pick up the files from the ELPA release and work with that? Maybe this is a topic for another thread. Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
> Stefan, how would I make the switch on elpa? The package recipe I've
> tested is this
>
> (auctex :url "https://git.savannah.gnu.org/git/auctex.git;
> :branch "main"
> :news "NEWS.org"
> :make "elpa"
> :doc ("doc/auctex.texi" "doc/preview-latex.texi"))
>
> Does pushing the new recipe in elpa-packages suffice?
Yes (tho we use a different indentation (for which there's no
auto-indent rules )).
Stefan
Re: Making AUCTeX ELPA releases from the master branch
Tassilo Horn writes:
> - There's also a completely different alternative: make the
> externals/elpa the new "main" branch and drop master and tarball
> releases altogether. Is there still a justification for having
> them? I mean, we dropped XEmacs support anyway and it should be
> easy enough for distros to just use the ELPA tarballs as basis for
> their distro packages.
I've created a "main" branch (split off externals/auctex) and adjusted
it such that it should be buildable on elpa and the mere act of changing
the Version number in auctex.el in a commit would trigger a new ELPA
release. And every other commit would at least trigger a new release on
ELPA-devel.
So basically, we should decide now if we switch to going ELPA-only in
which case we'd not use master anymore but develop directly in main.
(I'd be in favour of it, obviously.)
We could also keep master as our development branch and still use the
new "main" branch (which I would probably rename to "elpa" in that case)
for elpa and turn on auto-sync. It would be a bit less automatic: we'd
need to keep merging from master to the "main" / "elpa" regularly and
increment the Version manually for releases. But it's still better than
the status quo (less committed generated files; better Version
determination).
Stefan, how would I make the switch on elpa? The package recipe I've
tested is this
(auctex :url "https://git.savannah.gnu.org/git/auctex.git;
:branch "main"
:news "NEWS.org"
:make "elpa"
:doc ("doc/auctex.texi" "doc/preview-latex.texi"))
Does pushing the new recipe in elpa-packages suffice?
Bye,
Tassilo
Re: Making AUCTeX ELPA releases from the master branch
>> Duh: it's `:doc`, not `:manual`! >> Sorry! > Haha, and then it works just fine. ;-) Yay! Stefan
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: >>> [ This assumes that the `:manual ...` thingy does >>> successfully build the docs. ] >> >> This is where I'm not sure. At least it doesn't seem to have an effect >> when running "make auctex.tar" locally (as said in my other mail). The >> tar file only contains the *.info files and the dir file in doc/ which >> are build by running "make all". > > Duh: it's `:doc`, not `:manual`! > Sorry! Haha, and then it works just fine. ;-) Thanks! Tassilo
Re: Making AUCTeX ELPA releases from the master branch
> Yes, it is. But I need the distinction if the current version got > there just now (in HEAD) or previously. So just a "yes/no" kind of information? I wonder what you use it for. >> [ This assumes that the `:manual ...` thingy does >> successfully build the docs. ] > > This is where I'm not sure. At least it doesn't seem to have an effect > when running "make auctex.tar" locally (as said in my other mail). The > tar file only contains the *.info files and the dir file in doc/ which > are build by running "make all". Duh: it's `:doc`, not `:manual`! Sorry! Stefan
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes:
>>> Why do you need to look at diffs?
>> In order to extract the version number.
>
> I don't understand: it's right there in the file, you don't need the
> diffs to extract it, no?
Yes, it is. But I need the distinction if the current version got there
just now (in HEAD) or previously.
>> Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa
>> to build the docs again although the recipe's :make "all" did already
>> build them (but at the "wrong" location)?
>
> Yup (the two know nothing of each other).
Ok.
>> That would be ok for me; I would also be willing to add a special
>> elpa make target moving the files or generating another top-level dir
>> file.
>
> You could also replace the "make all" with another target that doesn't
> build the docs.
Yes, I can do that, too.
> [ This assumes that the `:manual ...` thingy does
> successfully build the docs. ]
This is where I'm not sure. At least it doesn't seem to have an effect
when running "make auctex.tar" locally (as said in my other mail). The
tar file only contains the *.info files and the dir file in doc/ which
are build by running "make all".
>> But I certainly want the additional benefit of having the docs
>> linked.
>
> That happens only if you use `:manual ...`.
Alright.
Bye,
Tassilo
Re: Making AUCTeX ELPA releases from the master branch
>> Why do you need to look at diffs?
> In order to extract the version number.
I don't understand: it's right there in the file, you don't need
the diffs to extract it, no?
> Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa to
> build the docs again although the recipe's :make "all" did already build
> them (but at the "wrong" location)?
Yup (the two know nothing of each other).
> That would be ok for me; I would also be willing to add a special elpa
> make target moving the files or generating another top-level dir file.
You could also replace the "make all" with another target that doesn't
build the docs.
[ This assumes that the `:manual ...` thingy does successfully
build the docs. ]
> But I certainly want the additional benefit of having the docs linked.
That happens only if you use `:manual ...`.
Stefan
Re: Making AUCTeX ELPA releases from the master branch
Tassilo Horn writes:
>> Our tarball build scripts can take care of building the Info files
>> and the `dir` (and moving them as needed), so maybe you can just add
>>
>> :manual ("doc/auctex.texi" "doc/preview-latex.texi")
>>
>> to the spec and that'll do the trick (with the advantage that the
>> manual will then also be made available at
>> `elpa.gnu.org/packages/doc/auctex.html`).
>
> Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa to
> build the docs again although the recipe's :make "all" did already
> build them (but at the "wrong" location)?
At least in my local tests, with
(auctex :url "https://git.savannah.gnu.org/git/auctex.git;
:news "NEWS.org"
:make "all"
:manual ("doc/auctex.texi" "doc/preview-latex.texi")
and then "make auctex.tar", the manuals & dir file are there only inside
doc/ where running :make "all" has generated them.
> That would be ok for me; I would also be willing to add a special elpa
> make target moving the files or generating another top-level dir file.
> But I certainly want the additional benefit of having the docs linked.
> Whatever is best for elpa.
Bye,
Tassilo
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes:
>> Why would I need the date of the last release?
>
> Don't know. I guess I misundersood what you meant by:
>
> Instead of looking at specially formatted lines in ChangeLog, it
> just looks at the git diffs to check when there was a "+;;
> Version: ..." change in auctex.el. ...
>
> Why do you need to look at diffs?
In order to extract the version number. Previously that was extracted
from ChangeLog which relied on the exact wording of release commits.
>> Oh, no, one thing doesn't: the fine manuals. I've changed it so that
>> they stay in doc/ and there's also the dir file referencing the
>> auctex and preview-latex manual. Do they need to be top-level for
>> elpa (in which case I'd just add an elpa make target doing the move)
>> or can I somehow make that work?
>
> Indeed, they need to be moved: `package.el` won't see your manual if
> the `dir` is not in the top-level directory (and the Info viewer won't
> search in subdirs, so either you need the Info files to be at
> top-level or you need to change the `dir` file so it refers to
> `doc/auctex`).
Ok.
> Our tarball build scripts can take care of building the Info files and
> the `dir` (and moving them as needed), so maybe you can just add
>
> :manual ("doc/auctex.texi" "doc/preview-latex.texi")
>
> to the spec and that'll do the trick (with the advantage that the
> manual will then also be made available at
> `elpa.gnu.org/packages/doc/auctex.html`).
Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa to
build the docs again although the recipe's :make "all" did already build
them (but at the "wrong" location)?
That would be ok for me; I would also be willing to add a special elpa
make target moving the files or generating another top-level dir file.
But I certainly want the additional benefit of having the docs linked.
Whatever is best for elpa.
Bye,
Tassilo
Re: Making AUCTeX ELPA releases from the master branch
>> The "%H" above makes it output the commit hash where `Version:` was
>> changed, so you can replace that with an appropriate % thingy to get
>> the date instead.
> Why would I need the date of the last release?
Don't know. I guess I misundersood what you meant by:
Instead of looking at specially formatted lines in ChangeLog, it just
looks at the git diffs to check when there was a "+;; Version: ..."
change in auctex.el. ...
Why do you need to look at diffs?
> Oh, no, one thing doesn't: the fine manuals. I've changed it so that
> they stay in doc/ and there's also the dir file referencing the auctex
> and preview-latex manual. Do they need to be top-level for elpa (in
> which case I'd just add an elpa make target doing the move) or can I
> somehow make that work?
Indeed, they need to be moved: `package.el` won't see your manual if the
`dir` is not in the top-level directory (and the Info viewer won't
search in subdirs, so either you need the Info files to be at top-level
or you need to change the `dir` file so it refers to `doc/auctex`).
Our tarball build scripts can take care of building the Info files and
the `dir` (and moving them as needed), so maybe you can just add
:manual ("doc/auctex.texi" "doc/preview-latex.texi")
to the spec and that'll do the trick (with the advantage that the
manual will then also be made available at
`elpa.gnu.org/packages/doc/auctex.html`).
Stefan
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: Hi Stefan, > FWIW, the `elpa-admin.el` code needs to do something similar and it > asks Git a bit more directly (i.e. with the generating the diff): > >(elpaa--call > (current-buffer) > "git" "log" "-n1" "--oneline" "--no-patch" > "--pretty=format:%H" > (when (elpaa--spec-get pkg-spec :merge) > ;; Finding "the" revision when there's a merge involved is > ;; fundamentally unreliable. > ;; Ideally we should probably signal an error when the > commit > ;; we found is not on all paths from FROM to avoid making an > ;; arbitrary choice. > ;; For `:merge'd packages, the commit that flipped > `Version:' > ;; is usually not what we want, since that one was on the > ;; upstream branch, without our own changes. > ;; We use `--first-parent' for this reason, so it prefers > ;; the corresponding merge commit (which is not ideal either > ;; but is arguably the best we can do in that case). > "--first-parent") > "-L" (concat "/^;;* *\\(Package-\\)\\?Version:/,+1:" > (file-name-nondirectory > (elpaa--main-file pkg-spec))) > > The "%H" above makes it output the commit hash where `Version:` was > changed, so you can replace that with an appropriate % thingy to get > the date instead. Why would I need the date of the last release? I set AUCTEXDATE to the committer date of HEAD, not to the date of the last release. When the Version is changed, then that's the correct release date, too. Otherwise, the current HEAD's date and time are appended to the last released version to indicate that this is a development version. > But another option is to disregard the problem: Perfect, exactly my style. YOLO! :-) > presumably you trust AUCTeX's code, Don't know. It's mostly Keite and Arash recently... :-P > so you don't need to run that make recipe within a sandbox to confine > its misdeeds, and the above error will not appear on `elpa.gnu.org`. > So, instead of (or in addition to, if you prefer) the above (debug t) > thingy, put: > > (sandbox nil) > > so the commands are run without Bubblewrap. Great, works. The build and also the package after package-install-file with the built auctex.tar. Oh, no, one thing doesn't: the fine manuals. I've changed it so that they stay in doc/ and there's also the dir file referencing the auctex and preview-latex manual. Do they need to be top-level for elpa (in which case I'd just add an elpa make target doing the move) or can I somehow make that work? Thanks, Tassilo
Re: Making AUCTeX ELPA releases from the master branch
> Alright, I've had some time to do some fiddling. In the auctex > repository, there's some new main branch (based on externals/auctex) > where I've changed how AUCTEXVERSION and AUCTEXDATE are determined. > Instead of looking at specially formatted lines in ChangeLog, it just > looks at the git diffs to check when there was a "+;; Version: ..." > change in auctex.el. It seems to work fine when I run "make -f > GNUMakefile". FWIW, the `elpa-admin.el` code needs to do something similar and it asks Git a bit more directly (i.e. with the generating the diff): (elpaa--call (current-buffer) "git" "log" "-n1" "--oneline" "--no-patch" "--pretty=format:%H" (when (elpaa--spec-get pkg-spec :merge) ;; Finding "the" revision when there's a merge involved is ;; fundamentally unreliable. ;; Ideally we should probably signal an error when the commit ;; we found is not on all paths from FROM to avoid making an ;; arbitrary choice. ;; For `:merge'd packages, the commit that flipped `Version:' ;; is usually not what we want, since that one was on the ;; upstream branch, without our own changes. ;; We use `--first-parent' for this reason, so it prefers ;; the corresponding merge commit (which is not ideal either ;; but is arguably the best we can do in that case). "--first-parent") "-L" (concat "/^;;* *\\(Package-\\)\\?Version:/,+1:" (file-name-nondirectory (elpaa--main-file pkg-spec))) The "%H" above makes it output the commit hash where `Version:` was changed, so you can replace that with an appropriate % thingy to get the date instead. > Now I'd like to test building auctex.tar using your recipe. I've > checked out that new main branch into ../elpa/packages/auctex/ (or > actually auctex is a symlink to my auctex clone). With the current > elpa-packages recipe > >(auctex :url "https://git.savannah.gnu.org/git/auctex.git; >:news "NEWS.org") > > an auctex.tar is built successfully but apparently that didn't run the > GNUMakefile, for example, tex-site.el isn't included because it's not > generated from tex-site.el.in. Indeed, by default we don't run any make or any such thing, we just tar up the files. > So I've tried to add :make "all" or even :shell-command "make -g > GNUMakefile" to the auctex recipe Sounds good. > but then I get this error: > > --8<---cut here---start->8--- > ❯ make auctex.tar > emacs --batch -Q -l admin/elpa-admin.el \ > -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk > emacs --batch -l /home/horn/tmp/elpa/admin/elpa-admin.el\ > -f elpaa-batch-make-one-tarball auctex.tar > Building tarball auctex.tar... > Build error for auctex.tar: (error "Error-indicating exit code in > elpaa--call-sandboxed: > bwrap: Can't bind mount /oldroot/home/horn/Repos/el/auctex on > /newroot/home/horn/tmp/elpa/packages/auctex/: Unable to mount source on > destination: No such file or directory > ") > Build of package auctex.tar FAILED!! > --8<---cut here---end--->8--- > > What does that error try to tell me? Good question. I haven't seen this error yet, so I don't know. Maybe the problem is in the "actually auctex is a symlink to my auctex clone". If you want to try and debug this, then edit the `elpa-config` file to put (debug t) in the config, so that you'll get a much more verbose output showing for example exactly the `bwrap` command executed, which you can then reproduce "by hand". But another option is to disregard the problem: presumably you trust AUCTeX's code, so you don't need to run that make recipe within a sandbox to confine its misdeeds, and the above error will not appear on `elpa.gnu.org`. So, instead of (or in addition to, if you prefer) the above (debug t) thingy, put: (sandbox nil) so the commands are run without Bubblewrap. Stefan
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: Hi Stefan, > Well, not for `make auctex.tar` where it's built from whatever is HEAD > in `packages/auctex`. But in `elpa.gnu.git` HEAD is indeed pointing > to `externals/`. Alright, I've had some time to do some fiddling. In the auctex repository, there's some new main branch (based on externals/auctex) where I've changed how AUCTEXVERSION and AUCTEXDATE are determined. Instead of looking at specially formatted lines in ChangeLog, it just looks at the git diffs to check when there was a "+;; Version: ..." change in auctex.el. It seems to work fine when I run "make -f GNUMakefile". Now I'd like to test building auctex.tar using your recipe. I've checked out that new main branch into ../elpa/packages/auctex/ (or actually auctex is a symlink to my auctex clone). With the current elpa-packages recipe (auctex :url "https://git.savannah.gnu.org/git/auctex.git; :news "NEWS.org") an auctex.tar is built successfully but apparently that didn't run the GNUMakefile, for example, tex-site.el isn't included because it's not generated from tex-site.el.in. So I've tried to add :make "all" or even :shell-command "make -g GNUMakefile" to the auctex recipe but then I get this error: --8<---cut here---start->8--- ❯ make auctex.tar emacs --batch -Q -l admin/elpa-admin.el \ -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk emacs --batch -l /home/horn/tmp/elpa/admin/elpa-admin.el\ -f elpaa-batch-make-one-tarball auctex.tar Building tarball auctex.tar... Build error for auctex.tar: (error "Error-indicating exit code in elpaa--call-sandboxed: bwrap: Can't bind mount /oldroot/home/horn/Repos/el/auctex on /newroot/home/horn/tmp/elpa/packages/auctex/: Unable to mount source on destination: No such file or directory ") Build of package auctex.tar FAILED!! --8<---cut here---end--->8--- What does that error try to tell me? Thanks, Tassilo
Re: Making AUCTeX ELPA releases from the master branch
Hi Tassilo, Tassilo Horn writes: > Ah, no. What I mean is renaming the externals/elpa branch to "main" > (which I currently have set to push to > git.savannah.gnu.org/srv/git/emacs/elpa.git) in our own git > (git.sv.gnu.org:/srv/git/auctex.git) and then use that as the same way > as we're using master right now (and just leave master as it is right > now). > > And on ELPA's elpa-packages, we'd replace the `:manual-sync t` with > `:branch main` so that on every push to our new main branch a new > package version would appear on the ELPA devel archive and a new normal > ELPA package whenever one of us increments the Version: header in > auctex.el on the new main branch. thanks for the clarification, SGTM. Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
>> And nowhere in the elpa repository do I find some statement that for >> auctex the externals/auctex branch in elpa.git is to be used instead >> of the main or master branch of auctex.git. > It's always built from `externals/`. Well, not for `make auctex.tar` where it's built from whatever is HEAD in `packages/auctex`. But in `elpa.gnu.git` HEAD is indeed pointing to `externals/`. Stefan
Re: Making AUCTeX ELPA releases from the master branch
> So I could just replace packages/auctex with some other clone of > auctex.git? Yes. >> So your first and third steps above can happen at some other time. > Alright. But I currently don't understand how "make packages/auctex" > knows which commit to check out. The first `make packages/auctex` just does git worktree add packages/auctex externals/auctex you can `git clone .../auctex.git` there instead. > And nowhere in the elpa repository do I find some statement that for > auctex the externals/auctex branch in elpa.git is to be used instead > of the main or master branch of auctex.git. It's always built from `externals/`. The sync between those branches and an upstream (according to `:url`) is performed separately by another cron job (it could run on another machine, tho it currently doesn't). > [1] It just occurred to me that in all mails I've written about an > externals/elpa branch which is actually externals/auctex. Stefan
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: >> So just that I get it right, we'd do: >> >> - Make our former externals/elpa branch the new main branch >> - git checkout -b main externals/elpa && git push >> - Then clone elpa and setup the infrastructure as you said >> - Edit elpa-packages locally (but don't yet commit/push) >> - remove `:manual-sync t` >> - add `:branch "main"` and maybe `:make "elpa"` >> - Then "make packages/auctex" once >> - while (make auctex.tar is not satisfactory) >> - edit on our new main branch, e.g., refine the elpa target >> - commit and push the modifications to the auctex recipe in >> elpa-packages > > Pretty much, yes. > > Note that `make auctex.tar` doesn't care about branches and remote > repositories, it just takes the commit currently found in > `packages/auctex` and makes a tarball from it (IOW things like `:url`, > `:manual-sync`, and `:branch` aren't used in the recipe, tho the rest > is). So I could just replace packages/auctex with some other clone of auctex.git? > So your first and third steps above can happen at some other time. Alright. But I currently don't understand how "make packages/auctex" knows which commit to check out. I mean, the elpa-packages auctex recipe has auctex.git as :url but auctex.git doesn't contain the externals/auctex branch but only elpa.git does. And nowhere in the elpa repository do I find some statement that for auctex the externals/auctex branch in elpa.git is to be used instead of the main or master branch of auctex.git. Is there some general rule that a package foo will be built from the HEAD of the externals/foo elpa.git branch if such a branch exists discarding what's specified as `:url` and `:branch` in the foo package recipe? Bye, Tassilo [1] It just occurred to me that in all mails I've written about an externals/elpa branch which is actually externals/auctex.
Re: Making AUCTeX ELPA releases from the master branch
> So just that I get it right, we'd do: > > - Make our former externals/elpa branch the new main branch > - git checkout -b main externals/elpa && git push > - Then clone elpa and setup the infrastructure as you said > - Edit elpa-packages locally (but don't yet commit/push) > - remove `:manual-sync t` > - add `:branch "main"` and maybe `:make "elpa"` > - Then "make packages/auctex" once > - while (make auctex.tar is not satisfactory) > - edit on our new main branch, e.g., refine the elpa target > - commit and push the modifications to the auctex recipe in > elpa-packages Pretty much, yes. Note that `make auctex.tar` doesn't care about branches and remote repositories, it just takes the commit currently found in `packages/auctex` and makes a tarball from it (IOW things like `:url`, `:manual-sync`, and `:branch` aren't used in the recipe, tho the rest is). So your first and third steps above can happen at some other time. Stefan
Re: Making AUCTeX ELPA releases from the master branch
Uwe Brauer via Discussion list for AUCTeX developers
writes:
>> - There's also a completely different alternative: make the
>> externals/elpa the new "main" branch and drop master and tarball
>> releases altogether. Is there still a justification for having
>> them? I mean, we dropped XEmacs support anyway and it should be
>> easy enough for distros to just use the ELPA tarballs as basis for
>> their distro packages.
>
> Just to be sure.
> For any of these two proposals:
>
> It would be still possible to pull (fetch) and compile auctex
> independently of emacs?
Yes, although I'd recommend to use the ELPA-devel package which would
automatically be built for every new commit so that you don't have to
hassle with pulling and building yourself.
For example, I use some packages from the ELPA devel archive like so:
--8<---cut here---start->8---
(add-to-list 'package-archives
'("gnu-devel" . "https://elpa.gnu.org/devel/;) t)
(setopt package-archive-priorities
'(("gnu" . 10)
("nongnu" . 10)
("melpa" . 10)
;; Lower priority because I want to explicitly define for a single
;; package that this archive is to be used by pinning it there.
("gnu-devel" . 0)))
(use-package ef-themes
:ensure t
;; Use the bleeding-edge package from gnu-devel instead of the
;; released version from the gnu ELPA archive.
:pin gnu-devel
...)
--8<---cut here---end--->8---
Bye,
Tassilo
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: >> --8<---cut here---start->8--- >> 2024-01-17 Mosè Giordano >> >> * Version 13.3 released. >> --8<---cut here---end--->8--- >> >> on top. So how should that work for ELPA releases? > > For GNU ELPA releases,the "main" place where you keep version numbers > should be your "main file", ideally `auctex.el`. > > So your make target will want to extract the version from there instead > of from the ChangeLog. But that should be easy. The "right" way would > be to fire an Emacs process and use `package-buffer-info` or just > `lm-header` to fetch the info. But I'd use a `sed` one-liner. > > That won't give you a date, tho. You could try and use Git to find a > corresponding date, but personally, I'd just use the current date > instead. Yes, something like this. >> - There's also a completely different alternative: make the >> externals/elpa the new "main" branch and drop master and tarball >> releases altogether. Is there still a justification for having >> them? I mean, we dropped XEmacs support anyway and it should be >> easy enough for distros to just use the ELPA tarballs as basis for >> their distro packages. > > That's what I'd do if I were you, indeed. No objections from me. > But note that this will still require tweaking the GNUmakefile to > fetch the Version from the new place and a few things like that and > changing the recipe to add something like `:make "elpa"`. Yes, but I think getting that right would be much easier than adding a similar target to the build infrastructure on master. >> - Mostly to Stefan: How can we test that safely? I guess we'll >> find some more issues. I don't want to edit the AUCTeX recipe in >> elpa-packages and then deploy broken packages to users. > > You can also try and reproduce the build locally as follows: > > git clone --single-branch https://git.sv.gnu.org/git/emacs/elpa > cd elpa > make # Setup the infrastructure > make packages/auctex # Create a worktree of the package > make auctex.tar # Build the tarballs into `auctex.tar` > > Note that the tarball is built from *the commit* rather than from the > current set of files (i.e. we start with `git stash` and we `git clean` > as well, IIRC, so be forewarned that it can throw away uncommitted data). So just that I get it right, we'd do: - Make our former externals/elpa branch the new main branch - git checkout -b main externals/elpa && git push - Then clone elpa and setup the infrastructure as you said - Edit elpa-packages locally (but don't yet commit/push) - remove `:manual-sync t` - add `:branch "main"` and maybe `:make "elpa"` - Then "make packages/auctex" once - while (make auctex.tar is not satisfactory) - edit on our new main branch, e.g., refine the elpa target - commit and push the modifications to the auctex recipe in elpa-packages Bye, Tassilo
Re: Making AUCTeX ELPA releases from the master branch
Arash Esbati writes: Hi Arash, >> - There's also a completely different alternative: make the >> externals/elpa the new "main" branch and drop master and tarball >> releases altogether. Is there still a justification for having >> them? > > Reg. dropping master: Do you mean we use ELPA as our master repo? Ah, no. What I mean is renaming the externals/elpa branch to "main" (which I currently have set to push to git.savannah.gnu.org/srv/git/emacs/elpa.git) in our own git (git.sv.gnu.org:/srv/git/auctex.git) and then use that as the same way as we're using master right now (and just leave master as it is right now). And on ELPA's elpa-packages, we'd replace the `:manual-sync t` with `:branch main` so that on every push to our new main branch a new package version would appear on the ELPA devel archive and a new normal ELPA package whenever one of us increments the Version: header in auctex.el on the new main branch. > I'm not sure what that means, but many projects use an external repo > and then sync a release with ELPA by bumping the version number, IIUC. > We can go that route as well, right? Exactly. Bye, Tassilo
Re: Making AUCTeX ELPA releases from the master branch
>>> "TH" == Tassilo Horn writes: > Hi all, > some weeks ago, Philip Kaludercic saw a commit of mine triggering a new > AUCTeX ELPA release and asked why there were changes to files which > shouldn't be committed because they are generated from other files, > e.g., info files. > - There's also a completely different alternative: make the > externals/elpa the new "main" branch and drop master and tarball > releases altogether. Is there still a justification for having > them? I mean, we dropped XEmacs support anyway and it should be > easy enough for distros to just use the ELPA tarballs as basis for > their distro packages. Just to be sure. For any of these two proposals: It would be still possible to pull (fetch) and compile auctex independently of emacs? I am asking because gnus since some time is part of Emacs so upgrading gnus without upgrading emacs is not easy to say the least. Uwe Brauer -- I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the EU and NATO membership of Ukraine. smime.p7s Description: S/MIME cryptographic signature
Re: Making AUCTeX ELPA releases from the master branch
Tassilo Horn writes: > I think it would be great if we could make it so that everyone of us > could trigger a new ELPA release directly from the master branch by just > incrementing the Version header which currently resides in auctex.el Hi Tassilo, besides the issues we have to resolve, I think this a really good idea which we should pursue. > - There's also a completely different alternative: make the > externals/elpa the new "main" branch and drop master and tarball > releases altogether. Is there still a justification for having > them? Reg. dropping master: Do you mean we use ELPA as our master repo? I'm not sure what that means, but many projects use an external repo and then sync a release with ELPA by bumping the version number, IIUC. We can go that route as well, right? I'm fond of dropping the official tarball release and let the distro packagers pick up AUCTeX at their convenience. The main reason for me triggering a tarball is sending a signal that the project is still alive and kicking (sort of). But we should seek for other ways, a tarball release is still work at our end. > I mean, we dropped XEmacs support anyway and it should be easy > enough for distros to just use the ELPA tarballs as basis for their > distro packages. @Davide: What do you think about this? Best, Arash
Re: Making AUCTeX ELPA releases from the master branch
Tassilo Horn [2024-04-09 14:09:53] wrote:
> Hi all,
>
> some weeks ago, Philip Kaludercic saw a commit of mine triggering a new
> AUCTeX ELPA release and asked why there were changes to files which
> shouldn't be committed because they are generated from other files,
> e.g., info files.
>
> The reason is that at the time where we added AUCTeX to ELPA (and
> created the externals/elpa branch for that purpose), the ELPA machinery
> wasn't able to perform our normal build procedure. But Stefan Monnier
> chimed in and suggested that nowadays, those issues are most probably
> resolved or can be resolved in some less drastic way than a separate
> branch. For example, building info manuals from multiple texi files
> residing in subdirectories are no problem anymore (one can specify `:doc
> ("doc/auctex.texi" "doc/preview-latex.texi")` in the ELPA package
> recipe) and we could have a separate elpa target in our Makefile and
> specify that as `:make "elpa"` in package recipe.
>
> I think it would be great if we could make it so that everyone of us
> could trigger a new ELPA release directly from the master branch by just
> incrementing the Version header which currently resides in auctex.el on
> the externals/elpa branch but which is generated from auctex.el.in on
> the master branch so not suitable for a Version header. But no problem,
> the elpa recipe could specify some different `:main-file`.
>
> So basically, I see these challenges:
>
> - We set the AUCTeX/preview version and date in the texi files from
> AUCTEXVERSION, AUCTEXDATE, PREVIEWVERSION, and PREVIEWDATE which are
> guessed by autoconf from the ChangeLog.1 and ChangeLog-preview files
> which arranges that the *VERSION is just the same as the *DATE if
> the top entry in the ChangeLogs is not a release entry in which case
> the version is extracted there.
>
> These ChangeLogs aren't usually edited. Currently, the tarball
> release process prepends the changes since the last tarball release,
> and then the "release manager" (Mosè) adds an entry like
>
> --8<---cut here---start->8---
> 2024-01-17 Mosè Giordano
>
> * Version 13.3 released.
> --8<---cut here---end--->8---
>
> on top. So how should that work for ELPA releases?
For GNU ELPA releases,the "main" place where you keep version numbers
should be your "main file", ideally `auctex.el`.
So your make target will want to extract the version from there instead
of from the ChangeLog. But that should be easy. The "right" way would
be to fire an Emacs process and use `package-buffer-info` or just
`lm-header` to fetch the info. But I'd use a `sed` one-liner.
That won't give you a date, tho. You could try and use Git to find
a corresponding date, but personally, I'd just use the current date instead.
> - There's also a completely different alternative: make the
> externals/elpa the new "main" branch and drop master and tarball
> releases altogether. Is there still a justification for having
> them? I mean, we dropped XEmacs support anyway and it should be
> easy enough for distros to just use the ELPA tarballs as basis for
> their distro packages.
That's what I'd do if I were you, indeed.
But note that this will still require tweaking the GNUmakefile to fetch the
Version from the new place and a few things like that and changing the
recipe to add something like `:make "elpa"`.
> - Mostly to Stefan: How can we test that safely? I guess we'll find
> some more issues. I don't want to edit the AUCTeX recipe in
> elpa-packages and then deploy broken packages to users.
You can also try and reproduce the build locally as follows:
git clone --single-branch https://git.sv.gnu.org/git/emacs/elpa
cd elpa
make # Setup the infrastructure
make packages/auctex # Create a worktree of the package
make auctex.tar # Build the tarballs into `auctex.tar`
Note that the tarball is built from *the commit* rather than from the
current set of files (i.e. we start with `git stash` and we `git clean`
as well, IIRC, so be forewarned that it can throw away uncommitted data).
Once that's working, we can install it in `elpa.git` but without
changing the `Version:` header so it doesn't trigger a release: it will
still trigger building a new tarball in GNU-devel ELPA so we can confirm
that it all works according to plans. And once we're satisfied with
http://elpa.gnu.org/devel/auctex.html, all that remains is to bump up
the `Version:`.
Stefan
Making AUCTeX ELPA releases from the master branch
Hi all,
some weeks ago, Philip Kaludercic saw a commit of mine triggering a new
AUCTeX ELPA release and asked why there were changes to files which
shouldn't be committed because they are generated from other files,
e.g., info files.
The reason is that at the time where we added AUCTeX to ELPA (and
created the externals/elpa branch for that purpose), the ELPA machinery
wasn't able to perform our normal build procedure. But Stefan Monnier
chimed in and suggested that nowadays, those issues are most probably
resolved or can be resolved in some less drastic way than a separate
branch. For example, building info manuals from multiple texi files
residing in subdirectories are no problem anymore (one can specify `:doc
("doc/auctex.texi" "doc/preview-latex.texi")` in the ELPA package
recipe) and we could have a separate elpa target in our Makefile and
specify that as `:make "elpa"` in package recipe.
I think it would be great if we could make it so that everyone of us
could trigger a new ELPA release directly from the master branch by just
incrementing the Version header which currently resides in auctex.el on
the externals/elpa branch but which is generated from auctex.el.in on
the master branch so not suitable for a Version header. But no problem,
the elpa recipe could specify some different `:main-file`.
So basically, I see these challenges:
- We set the AUCTeX/preview version and date in the texi files from
AUCTEXVERSION, AUCTEXDATE, PREVIEWVERSION, and PREVIEWDATE which are
guessed by autoconf from the ChangeLog.1 and ChangeLog-preview files
which arranges that the *VERSION is just the same as the *DATE if
the top entry in the ChangeLogs is not a release entry in which case
the version is extracted there.
These ChangeLogs aren't usually edited. Currently, the tarball
release process prepends the changes since the last tarball release,
and then the "release manager" (Mosè) adds an entry like
--8<---cut here---start->8---
2024-01-17 Mosè Giordano
* Version 13.3 released.
--8<---cut here---end--->8---
on top. So how should that work for ELPA releases?
- There's also a completely different alternative: make the
externals/elpa the new "main" branch and drop master and tarball
releases altogether. Is there still a justification for having
them? I mean, we dropped XEmacs support anyway and it should be
easy enough for distros to just use the ELPA tarballs as basis for
their distro packages.
- Mostly to Stefan: How can we test that safely? I guess we'll find
some more issues. I don't want to edit the AUCTeX recipe in
elpa-packages and then deploy broken packages to users.
Bye,
Tassilo
