On 04.03.2013 10:00, Richard Frith-Macdonald wrote: > the first, smaller patch, to change configure.ac and the cofig.h.in and > base.make.in files to detect the presence/usability of libdispatch (would we > only consider it usable if we had block support?),
We already have a working check for libdispatch, which automatically enables it for the concurrent collection enumeration/sorting/filtering stuff if it is usable together with libobjc2 (whether it is depends on whether you have the recent release of libBlocksRuntime). We don't even need blocks support for that, because we have a macro that can call a block even if the compiler doesn't support calling it directly. The changes Jean did to the configure scirpt seem to be to detect presence of his personal version of libdispatch, which introduces some callbacks that are not immediately obivous to me (with a _4GS suffix, so I expect they are required exclusively for GNUstep). I would prefer these changes to be explained and suggested for inclusion into the upstream libdispatch before we integrate those patches. I don't think we want to maintain what effectively constitutes a fork of libdisaptch that is only useful to us. Cheers, Niels
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
