Re: libstdthreads threads.h detection and gnulib

On Wed, Sep 11, 2024 at 10:51:50PM +0200, Antoine Jacoutot wrote:
> On Wed, Sep 11, 2024 at 10:13:12PM +0200, Jeremie Courreges-Anglas wrote:
> > (List found with grep '^checking for threads.h' on the latest amd64
> > build logs.)
> >
> > I can think of several approaches to fix this:
> >
> > 1. add libstdthreads as a build dep to all those ports. Simple but
> > slightly problematic:
> > - IIUC, brings no functional value
> > - increases the chance of libstdthreads being picked up by future ports
> >
> > 2. "poison" threads.h detection for gnu.port.mk ports. This should be
> > enough for the gnulib occurences.
> >
> > 3. move libstdthreads header and libs to a subdirectory, to avoid
> > threads.h being picked up just because it's in the commonly used
> > /usr/local/include directory.
> >
> > The diff below, tested with sysutils/ggrep, implements approach #2.
> > If a gnu.port.mk port really wants libstdthreads, one needs to add
> > devel/libstdthreads to BUILD_DEPENDS (even though it really belongs in
> > LIB_DEPENDS), or add an override in CONFIGURE_ENV.
> > The diff isn't complete: it lacks at least REVISION bumps for at least
> > octave, pspp and link-grammar, and possibly safety bumps for all other
> > affected ports; but it shows the intent.
> >
> > Approach #3 seems to work too but is slightly tricker. wayland/foot
> > would need a meson.build patch.
> >
> > Thoughts?
>
> I vote for #1.
> This is something we should have.
> #3 is horrible, we already struggle with such constructs in ports and honestly
> it's a pain (aka, this should be a short term solution that always ends up for
> eternity).
>
> Matthieu, should this be implemented / moved into base at some
> point?

Yes that's what I've been saying since c2k23 in Tallinn. The consensus
was to first add it in ports and wait.

Ihmo if it causes too much trouble for the release just un-hook it
again (with UNLINKED = wayland) together with fcft and foot.

No one will miss those ports. and we can work on this later again.

One difficulty to add it in base it that it doesn't build with
base-gcc as is.
--
Matthieu Herrb