I'll see what I can do.

On Fri, Dec 5, 2025 at 12:54 PM Stuart Henderson <stu@spacehopper.org>
wrote:

> Generally "private" headers are really not supposed to be installed.
> So that we don't need to include them in packages, is there a way to
> do this via BUILD_DEPENDS=devel/libdispatch:patch (or :configure or
> :build if the relevant header is a generated file) and point libobjc2
> at that via -I preprocessor flags instead?
>
> Obviously we'll need to pay more attention to libobjc2 if updating
> libdispatch if they're poking about in internals. I see there's a Test/
> directory, does that have anything we can use to verify operation? If
> so, can it be hooked up so that 'make test' runs it please?
>
> On 2025/12/04 20:34, Sebastian Reitenbach wrote:
> > Hi,
> >
> > x11/gnustep/libobjc2 provides it's own Blocks Runtime. In the current
> version it's installed a
> > bit out of the way to prevent trouble with devel/libdispatch. But when
> installing libdispatch,
> > and want to use libdispatch in an Objective-C project, then bad things
> happen, because the
> > Blocks runtimes in libdispatch and libobjc2 then kind of conflict. It's
> basically not usable.
> > The latest version of libobjc2 allows to disable internal Blocks
> Runtime, and use the one from
> > libdispatch. To actually be able to use it, the private headers for
> libdispatch are needed, or
> > in particular Block_private.h.
> >
> > Attached patch to devel/libdispatch finally allows me to use libdispatch
> in Objective-C
> > applications.
> >
> > comments, questions, or concerns are welcome, even OKs ;)
> >
> > thanks,
> > Sebastian
>
>
>