public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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



             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