Re: Is there any way to use ARC in 32-bit?

[Richard Frith-Macdonald]

On 29 Jan 2015, at 09:10, Richard Frith-Macdonald 
<richardfrithmacdonald@gmail.com> wrote:
> 
> On 28 Jan 2015, at 18:31, David Chisnall <theraven@sucs.org> wrote:
>> 
>> On 28 Jan 2015, at 17:49, Richard Frith-Macdonald 
>> <richardfrithmacdonald@gmail.com> wrote:
>> 
>>> When tryiung to move people over to using clang and libobjc2, everyone 
>>> seems to have problems with building libobjc2 because of its cmake 
>>> dependency :-(
>> 
>> People who can't manage:
>> 
>> $ mkdir Build ; cd Build
>> $ cmake ..
>> $ ccmake . # Optional, only do if you want to enter the curses UI to tweak 
>> configure options
>> $ make && make install
>> 
>> Probably are going to struggle with a lot of other things too...
> 
> Heh ... everything is simple if/when it works.  There are also people who 
> struggle with:
> 
> $ configure ... # Optional ... e.g. if you want to depend on stuff installed 
> strangely
> $ make install
> 
>>> I can certainly help with discussions and patch integration for 
>>> gnustep-make to better use clang, but almost as useful would be building 
>>> libobjc2 without requiring cmake.
>> 
>> You are *far* more likely to find developers familiar with CMake than 
>> GNUstep Make (or, in fact, pretty much any other build system).  To put some 
>> real numbers on this, in the FreeBSD ports tree there are 1018 ports that 
>> use CMake, 90 that use GNUstep Make.  For comparison, there are 399 that use 
>> autotools.
> 
> Different worlds ... on FreeBSD that's roughly 2:1 cmake to autotools, but I 
> guess it looks different in non-bsd systems.
> I'm dealing with people using flavours of gnu/linux.
> I have no idea what typical ms-windows people do when faced with either 
> autoconf or cmake ...
> 
> A

Oops ... accidentally sent too soon ...
I meant to add 

Anyway, the relative merits or popularity of autoconf against cmake are not 
really the issue for building gnustep stuff (if we assume libobjc2 is 
built/installed somewhere).

What we really need is good support for the next stage (building gnustep 
projects using gnustep-make) where most people want to use gcc/objc but a 
substantial (and rapidly growing) minority want to use clang/objc2.
There's good support for the gcc/objc combination, but not for clang/objc2 so 
far, and the people wanting to use clang/objc2 have not yet contributed patches 
to do it; mostly I think, put off by the fact that we don't want patches to 
*switch*, we want patches which will support both old *and* new.

I favour using the library-combo feature to switch between old style and new 
style, with the addition of a new runtime library designation (perhaps oc2 for 
the new runtime).
So instead of gnu-gnu-gnu for gnustep-gui with fgnustep-base and the gnu 
runtime, we might use gnu-gnu-oc2 for building using the new runtime.

In the interests of simplicity I'd favour making compiler support be tied to 
the runtime:
So we would drop any official support for clang in conjunction with the old 
runtime (gnu-gnu-gnu combo) and we would make support for gnu-gnu-oc2 *require* 
a reasonably recent version of clang

Does that make sense?



--- 

Reply encrypted using 
http://keys.gnupg.net:11371/pks/lookup?op=get&search=0x3EC26D605B89D6F6