On Mon, Mar 23, 2026 at 08:59:47PM +0100, Jeremie Courreges-Anglas wrote:
> There may be a followup commit if people feel like moving back consumers
> to a default COMPILER line makes sense, mail to follow.
> Here's said email. kmos added a COMPILER line to the following ports
> because of libnotify (commit messages looked consistent so I doubt I
> mised one).
> audio/gmpc
> geo/geoclue2
> sysutils/tray-app
> www/uget
> x11/gnome/settings-daemon
> x11/mate/caja
> x11/mate/settings-daemon
> If I revert the COMPILER addition in said ports, they still build on
> sparc64. However libnotify looks like an active project and its
> main/only use is gui programs, so most of them already need a more
> recent compiler, and I'd hate to waste Kurt's time on something he
> already fixed.
> Here's the -current list of devel/libnotify
> consumers using the default COMPILER = base-clang base-gcc value,
> along with the reason why they weren't built in the last sparc64 bulk:
> mail/evolution missing dep webkitgtk4
> productivity/osmo missing dep webkitgtk4
> x11/gnome-mplayer old port, libnotify header error
> x11/mate/notification-daemon missing dep webkitgtk4
> x11/pidgin-libnotify old port, libnotify header error
> Here's the diff that reverts the COMPILER addition in libnotify
> consumers. It slightly decreases the amounts of deps needed to build
> those ports, but as far as I'm concerned, these ports can stay as is
> and I'd happily drop the diff.
> Kurt, others: thoughts?
I don't have strong feelings either way. base-gcc is generally a much
quicker compiler than ports-gcc, so it could be a decent time saver
on more complex ports. Theoretially reverting them will also give more
ports that may still build on the other base-gcc arches that we don't
build packages for.
--Kurt
No comments:
Post a Comment