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

Reply via email to