Re: compiling GNUstep on OpenBSD - various compiler/runtime options

[Richard Frith-Macdonald]

> On 3 Jan 2020, at 00:34, Riccardo Mottola <address@hidden> wrote:
> 
> Hi All!
> 
> 
> I am testing Niels' fork of make... and OpenBSD is one of the candidates, 
> since I have since long issues with gcc there. I hope we can fix it because I 
> like what Niels is doing there.
> 
> Just to make some clarity, let me sum up what is my knowledge:
> 
> We have two compilers: gcc and clang.
> 
> We have two runtime libraries: gcc one and libobjc2 in our repo by David. 
> David's runtime can be used in "gnu" and "ng" mode. Correct? However there is 
> no need to configure it, it is the same library built and installed the same 
> which then supports both (save bugs).
> 
> GCC of course supports only "gnu", its own runtime and and libobjc2 but only 
> in "gnu" mode.
> 
> Clang can be again used in both ng and gnu, but of course only with libobjc2 
> since it has no own runtime.
> 
> This gives us the following combinations possible:
> 
> 1) gcc + own runtime (make detects this config all by itself)
> 
> 2) gcc + libobjc2 (make configured with gnu-gnu-gnu)
> 
> 3) clang + libobjc2 and make configured gnu-gnu-gnu
> 
> 4) clang + libobjc2 and make configured ng-gnu-gnu


The introduction of the ng runtime specification was supposed to mean that we 
*don't* have those four options:  it means we support only two setups
 (1) and (4) above.  The combinations you list as (2) and (3) are 
unsupported/invalid because
1. means the original (also called legacy) objc
4. means all the latest next-gen stuff (next-gen because we didn't want to use 
the objc-2.0 lable)
There's nothing in between as a simple recognition of the realities of what 
compiler works reliably with each runtime.
In practice, clang may be able to build code for the old runtime (so 
individuals might get 3 to work for them, but we can't support them)