Re: Embedded blocks...

[Yavor Doganov]

Jordan Schidlowsky wrote:
> > On Oct 31, 2019, at 2:47 PM, Yavor Doganov <address@hidden> wrote:
> > I fixed a bug in SOPE on SuperH just a few months ago.  Over the
> > years, I recall fixes in GNUstep core libraries on HP-PA, GNU/Hurd
> > and GNU/kFreeBSD, to name a few.  And non-core packages on sparc,
> > ppc, ppc64, powerpcspe and m68k.

> Aren't all the listed architectures actually already supported in
> the latest llvm backend?  sparc, ppc, ppc64, powerpcspe and m68k all
> seem supported no?  I don't know if moving to clang would actually
> mean dropping support for these archs...

PowerPC flavors are supported, yes.  But not alpha, hppa, ia64, m68k,
riscv64, sh4, x32, hurd and kfreebsd.

> Also, i dunno, but I think when a new architecture arises it may
> actually be easier to support it in llvm in the future...  I don't
> know why this would be more effort in clang than any other compiler.

I don't know either but the RISCV porters said it was easier for them
to support GCC.

But I was talking about something different -- supporting a new
architecture is not only a toolchain issue.  The ppc64el porters are
still sending patches for packages that don't build successfully on
ppc64el and it's not exactly a new architecture.  GNUstep seldom needs
arch-specific patches (we didn't need to add any for riscv64) but some
other packages do.  If you restrict the build tests of particular
software only to a certain set of architectures it is possible that
its portability could decrease as time goes by.

Bertrand Dekoninck wrote:
> There should be some reasons why debian sticked to it.

As I said: there is no practical benefit.  More cons than pros.

There's also the Debian Policy which says that packages should be
built with the default compiler unless absolutely necessary.  It also
says that a package is buggy if it built on some architecture but that
is no longer the case.

> I don't know if there are plans to switch to libobjc2.

As it stands, no.  If the situation changes, we will reevaluate.  If
GNUstep drops GCC support we'll have no choice but to follow upstream.