Page MenuHomeFreeBSD

Guile ports: remove conflicts and add flavors
ClosedPublic

Authored by andrew_tao173.riddles.org.uk on May 21 2023, 8:22 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Dec 1, 8:23 PM
Unknown Object (File)
Wed, Nov 27, 1:14 PM
Unknown Object (File)
Wed, Nov 27, 5:53 AM
Unknown Object (File)
Mon, Nov 25, 10:15 AM
Unknown Object (File)
Mon, Nov 25, 10:15 AM
Unknown Object (File)
Sun, Nov 24, 2:09 PM
Unknown Object (File)
Sat, Nov 23, 9:55 AM
Unknown Object (File)
Fri, Nov 22, 10:43 PM

Details

Summary

Currently, the three Guile versions and their dependent ports conflict, preventing installation of more than one at a time. This is clearly unsatisfactory, so here is a fix for it.

What this does:

  1. Creates USES=guile[:options] and updates ports to use it.
  1. To help with conflicts over .pc files, USES=pkgconfig now allows you to specify PKGCONFIG_PATHS to allow management of PKG_CONFIG_PATHS in a cooperative fashion.
  1. Some specific Guile library ports (guile-lib, guile-cairo, slib-guile) have been flavorized.
  1. [Currently none of the lang/guileN ports install a plain "guile", they install guile1, guile-1.8, guile2, guile-2.2, guile3, guile-3.0 respectively. This could be changed; should "guile" refer to the latest version, or the default version?] As per fuz' suggestion, I re-added lang/guile as a metaport pointing to the default version.
  1. some PORTREVISIONs in this patch will be wrong, this will be re-checked after testing is complete
  1. This presumably needs a MOVED entry guile -> guile3, but I leave that to the committed because it makes rebasing a pain.
Test Plan

Tests done so far, all on amd64 unless stated:

  • install all three Guile versions at once and test clients of each: lilypond for guile1, guile-gnome-platform for guile2, and guile-cairo (via g-golf which is not yet a port) for guile3.
  • testport builds for all ports touched in the patch so far
  • actual runtime tests on guile-gnome-platform, guile-cairo, g-wrap, guile-lib, lilypond (w/ and w/o GUILE2 option), lilypond-devel, irc/weechat, finance/gnucash, audio/denemo, games/aisleriot, games/gnurobots, www/elinks
  • build guile3 on i386 to confirm it is not BROKEN as was previously specified
  • tested all ports for non-clean building

Tests planned:

  • test on i386 and armv7 if resources allow (I don't have an aarch64 system to test on).

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

andrew_tao173.riddles.org.uk edited the test plan for this revision. (Show Details)

Update with more ports, and improved logic in guile.mk.

andrew_tao173.riddles.org.uk edited the summary of this revision. (Show Details)
andrew_tao173.riddles.org.uk edited the test plan for this revision. (Show Details)

Rebase.

Add remaining guile ports; this should now be complete.

andrew_tao173.riddles.org.uk edited the test plan for this revision. (Show Details)

Rebase (on 4cec5e5f). Fix some minor issues.

andrew_tao173.riddles.org.uk edited the test plan for this revision. (Show Details)

Rebase on 738e4012 and fix:

  1. sysutils/mcron somehow got missed out; fix.
  2. Add new "conflicts" parameter to update CONFLICTS_BUILD
  3. Test all ports for non-clean build and add "conflicts" as needed
  4. Centralize some plist variables in guile.mk
  5. Adjust environment settings to try and maximize the chance that configure scripts will select the right guile version

It seems that a fair number of ports (mostly ones using cmake or meson for building) will not select the correct guile version when not doing a clean build. I have attempted to address this using CONFLICTS_BUILD (to at least give a useful error), but unfortunately it's hard to test this at present since CONFLICTS_BUILD is broken in the framework due to a known bug in pkg(8).

This issue could be solved in one of the following ways:

  1. Move the guile-x.y.pc files to GUILE_PKGCONFIG_DIR, so that only the requested version's .pc file can be found.
  2. Patch the configure scripts of the affected ports.

So far I have not done either, because (a) some of the affected ports don't build outside a clean environment anyway (e.g. mail/mailutils, which breaks in the presence of gnuradius), and (b) moving the .pc files to a non-default location other than when strictly needed is rather hostile to building software altogether outside of the ports framework. However I am open to argument on this point.

At this point I believe I have no further changes to make unless I discover a problem in my own work or issues are reported on this review.

Rebase (on c8adede0fca)

Centralize definition of info, docs and examples paths (based on experience of adding a new port with examples)

Disuse USE_LDCONFIG in graphics/guile-cairo based on an IRC discussion with bapt

Re-add lang/guile as a metaport that simply symlinks to the default version, based on IRC discussion with fuz

@bofh @andrew Could we get a decision on this one? LGTM, but I think portmgr needs to approve. Should get an exp-run, too.

This revision is now accepted and ready to land.Jul 28 2023, 12:01 PM

@bofh has approved of these changes in IRC. I plan to commit with my next batch after extensive build tests.

Changes I plan to make on commit:

  • change lang/guile version to 4 to avoid the version going backwards.
  • adjust various port revisions
  • add relevant bits to CHANGES and MOVED

I have split your work into three commits, could make it four if you like. You can find the state I intend to commit on git repository http://fuz.su/~fuz/ports.git, branch guile.

Pick up CHANGES, MOVED, and finalized PORTREVISION changes from fuz' repo.

Fix off_t bug in guile2 by taking the fix from the guile3 port. This turns out to have been a live bug for mail/mailutils with GUILE enabled on 32-bit platforms, detected by the new compiler strictness. (off_t would have been passed to a function call as the wrong type, possibly leading to garbage values depending on calling convention and file size.) Fix build-stamp issue in passing.

This revision now requires review to proceed.Jul 28 2023, 5:56 PM
This revision was not accepted when it landed; it landed in state Needs Review.Jul 30 2023, 10:59 PM
This revision was automatically updated to reflect the committed changes.

I will open a separate review shortly for documentation for this in the porters handbook.