From: "Arsen Arsenović" <arsen@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: "Arsen Arsenović" <arsen@gentoo.org>
Subject: [gentoo-dev] [RFC HELP WANTED 0/9] Mending the Guile ecosystem
Date: Mon, 12 Aug 2024 00:22:45 +0200 [thread overview]
Message-ID: <20240811231742.942813-1-arsen@gentoo.org> (raw)
Evening!
This patchset brings Gentoo a new set of ecosystem-style packages à la
Lua or Python. Now, the trouble with that is that we already have a
bunch of Guile packages in the Gentoo repositories:
~$ qdepends -Qt dev-scheme/guile | wc -l
85
... and more, probably.
My attempt to do this started last year(!), I got through about a third
of the ecosystem before running out of time. When I revisited, those
patches were (obviously) out-of-date and were difficult to rebase due to
the nature of our usage of Git, so that never got anywhere. So, bare
with me on the code as it might be partially stale and I might've missed
stuff when re-reviewing it.
The idea, like with Lua, is to do -r100 revisions where we use
the new Guile slots and keep them masked until the mass-unmask day. For
each ported/new package, add the appropriate mask to
profiles/package.mask under "Guile rework masks". If a package is
entirely fresh (e.g. www-apps/haunt), it is redundant to do -r100, and
so the entire package may be masked.
However, the eclasses are still relatively okay, and Sam persuaded me to
try a new approach - asking for help - so, here it is.
Anyway - the patch primarily consists of three eclasses:
- guile-utils.eclass, which provides some functionality useful to /all/
Guile ebuilds, as well as some common semi-private code between
guile.eclass and guile-single.eclass. It is usually not (ever?)
useful to inherit from it, but it does provide a few useful "end-user"
functions, namely guile_export, guile_unstrip_ccache,
guile_create_temporary_config, guile_bump_sources.
- guile-single.eclass, which is analogous to python-single-r1.eclass, is
useful for packages extended with Guile (gdb, make - included as an
example, gnucash come to mind) and to individual Guile programs
(haunt, which is included as an example). Packages using this eclass
cannot be "multi-installed".
- guile.eclass, which is the meat and potatoes of the ecosystem
mechanism. It contains the facilities required to build and
multi-version-able (?) Guile libraries (or potentially libraries with
an associated program picked from the best variant).
Packages using this eclass require most care - the ecosystem as it
stands right now is somewhat inconsistent in terms of build systems
and conventions, so there might be need to patch on occasion. For
instance, I know from previous porting attempts that guile-lib
installs files that depend on the configure-time Guile version in an
unversioned directory. This is very bad for us. The eclass also
won't detect this (to be consistent with multibuild.eclass and because
working around it would be difficult when needed), rather, it works on
a "best variant wins" basis.
To prevent such a conflict, one should check where the package
installs its files. Usually, scripts should end up in (%site-dir),
their corresponding .go files should be in (%site-ccache-dir). But,
if, say, the source scripts (in (%site-dir)) don't depend on the Guile
version they're being configured for and they're being installed
unversioned, it is probably OK to leave them as-is.
For the guile-lib example above, one version-dependent but unslotted
file that the build system installs is a pkg-config file called
guile-lib-1.0.pc. This file does not appear to do much but it does
contain a reference to the (%site-ccache-dir), which is certainly
slotted, and so, can't be left there. Installing it into
/usr/share/guile-data/${GUILE_CURRENT_VERSION}/pkgconfig is probably
okay. If in doubt, duplicate the possibly non-version-dependent
files. This is always safe, and more consistent.
Sometimes, one might need to modify the build system of these packages
to achieve the above. We should strive, as usual, to get those
patches uptream.
* Porting notes
I recommend testing in a container that does not have a /usr/bin/guile
symlink, has minimal USE on dev-scheme/guile (so that you can notice if
you need GUILE_REQ_USE="deprecated", for instance). Always check
package contents and see if there are any files that seem like they
should get a copy per Guile version but didn't.
Never forget to use GUILE_REQUIRED_USE, GUILE_DEPS, guile_bump_sources,
guile_unstrip_ccache or guile{,-single}_pkg_setup, as well as
guile_gen_cond_dep for guile-single packages, if applicable.
Please ping me with any questions and to review code, as well as for
novel situations so that we may decide what to do about them. The
appropriate channel for this discussion is #gentoo-lisp.
* TODO list
- Checks for bad shebangs and references to the unversioned Guile
executable
- More 'static' checks if possible (e.g. ensuring GUILE_REQUIRED_USE was
used, ditto for GUILE_DEPS etc)
- Making sure that GUILE_COMPAT is in ascending order
- Fixing bugs
- guile.eselect
Thank you all in advance, both for the help and for bearing with me. I
imagine this won't be the last revision.
Have a lovely evening!
Arsen Arsenović (9):
guile-utils.eclass: new eclass, common code for guile packages
guile-single.eclass: new eclass, for single-impl guile packages
guile.eclass: new eclass, for guile multi-impl packages
profiles/base: add guile _TARGETS USE_EXPAND variables
dev-build/make: switch to new guile mechanism
dev-scheme/guile-reader: port to new guile eclasses
dev-scheme/guile-commonmark: new package, add 0.1.2_pre20240803
www-apps/haunt: new package, add 0.3.0
dev-scheme/slib: add 3c1, port to new guile eclasses
dev-build/make/make-4.4.1-r100.ebuild | 102 +++++
dev-build/make/make-9999.ebuild | 14 +-
dev-scheme/guile-commonmark/Manifest | 1 +
.../guile-commonmark-0.1.2_pre20240803.ebuild | 29 ++
dev-scheme/guile-commonmark/metadata.xml | 15 +
.../guile-reader-0.6.3-implicit-fn-decl.patch | 25 ++
.../files/guile-reader-0.6.3-slot.patch | 66 ++++
.../guile-reader-0.6.3-r100.ebuild | 60 +++
dev-scheme/slib/Manifest | 1 +
dev-scheme/slib/slib-3.3.1-r100.ebuild | 123 ++++++
eclass/guile-single.eclass | 245 ++++++++++++
eclass/guile-utils.eclass | 277 ++++++++++++++
eclass/guile.eclass | 358 ++++++++++++++++++
profiles/base/make.defaults | 8 +-
profiles/desc/guile_single_target.desc | 7 +
profiles/desc/guile_targets.desc | 7 +
profiles/package.mask | 5 +
www-apps/haunt/Manifest | 1 +
www-apps/haunt/haunt-0.3.0.ebuild | 25 ++
www-apps/haunt/metadata.xml | 12 +
20 files changed, 1378 insertions(+), 3 deletions(-)
create mode 100644 dev-build/make/make-4.4.1-r100.ebuild
create mode 100644 dev-scheme/guile-commonmark/Manifest
create mode 100644 dev-scheme/guile-commonmark/guile-commonmark-0.1.2_pre20240803.ebuild
create mode 100644 dev-scheme/guile-commonmark/metadata.xml
create mode 100644 dev-scheme/guile-reader/files/guile-reader-0.6.3-implicit-fn-decl.patch
create mode 100644 dev-scheme/guile-reader/files/guile-reader-0.6.3-slot.patch
create mode 100644 dev-scheme/guile-reader/guile-reader-0.6.3-r100.ebuild
create mode 100644 dev-scheme/slib/slib-3.3.1-r100.ebuild
create mode 100644 eclass/guile-single.eclass
create mode 100644 eclass/guile-utils.eclass
create mode 100644 eclass/guile.eclass
create mode 100644 profiles/desc/guile_single_target.desc
create mode 100644 profiles/desc/guile_targets.desc
create mode 100644 www-apps/haunt/Manifest
create mode 100644 www-apps/haunt/haunt-0.3.0.ebuild
create mode 100644 www-apps/haunt/metadata.xml
--
2.45.2
next reply other threads:[~2024-08-11 23:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-11 22:22 Arsen Arsenović [this message]
2024-08-11 22:22 ` [gentoo-dev] [RFC HELP WANTED 1/9] guile-utils.eclass: new eclass, common code for guile packages Arsen Arsenović
2024-08-11 22:22 ` [gentoo-dev] [RFC HELP WANTED 2/9] guile-single.eclass: new eclass, for single-impl " Arsen Arsenović
2024-08-11 22:22 ` [gentoo-dev] [RFC HELP WANTED 3/9] guile.eclass: new eclass, for guile multi-impl packages Arsen Arsenović
2024-08-11 22:22 ` [gentoo-dev] [RFC HELP WANTED 4/9] profiles/base: add guile _TARGETS USE_EXPAND variables Arsen Arsenović
2024-08-11 22:22 ` [gentoo-dev] [RFC HELP WANTED 5/9] dev-build/make: switch to new guile mechanism Arsen Arsenović
2024-08-11 22:22 ` [gentoo-dev] [RFC HELP WANTED 6/9] dev-scheme/guile-reader: port to new guile eclasses Arsen Arsenović
2024-08-11 22:22 ` [gentoo-dev] [RFC HELP WANTED 7/9] dev-scheme/guile-commonmark: new package, add 0.1.2_pre20240803 Arsen Arsenović
2024-08-11 22:22 ` [gentoo-dev] [RFC HELP WANTED 8/9] www-apps/haunt: new package, add 0.3.0 Arsen Arsenović
2024-08-11 22:22 ` [gentoo-dev] [RFC HELP WANTED 9/9] dev-scheme/slib: add 3c1, port to new guile eclasses Arsen Arsenović
2024-08-18 9:29 ` [gentoo-dev] [RFC HELP WANTED 0/9] Mending the Guile ecosystem Sam James
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=20240811231742.942813-1-arsen@gentoo.org \
--to=arsen@gentoo.org \
--cc=gentoo-dev@lists.gentoo.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox