Re: Incompatible compiler option fexec-charset

[Richard Frith-Macdonald]

On 7 Dec 2011, at 17:12, Richard Frith-Macdonald wrote:

> 
> On 7 Dec 2011, at 16:43, David Chisnall wrote:
> 
>> On 7 Dec 2011, at 16:04, Richard Frith-Macdonald wrote:
>> 
>>> 2. The reason is that we now support non-ascii string literals for 
>>> compatibility with OSX.  Of course we don't use it ... because we didn't 
>>> support it before.
>> 
>> We don't support string literals at all!  The compiler supports them, not 
>> us.  If we are not using them, then we don't need this configure check (and 
>> a configure check that can safely be disabled and ignored is a pointless 
>> check anyway - reducing the number of executable configure checks, rather 
>> than expanding them, is also a good idea because they break cross 
>> compilation).
>> 
>> So I still don't understand why we have this.  As far as I can tell, 
>> removing it has no adverse effects, enabling it means that I now need to add 
>> an extra flag to configure and people keep appearing in the Étoilé SILC 
>> channel and asking me if I know why GNUstep is broken.
> 
> I did ask for volunteers, and said I didn't like writing autoconf tests and 
> didn't want to do this, and suggested possibly going though and documenting 
> the problem thoroughly to warn people ... but no response.  Which is why I 
> ended up having to go ahead and do it.   I guess the fact that you don't 
> understand it means that, 1 it needed doing and 2 it still needs doing better.
> 
> Anyway, I'll try to be clear/simple ...
> 
> Start with the premise that GNUstep is for users:  developers who write ObjC 
> code 9and we particularly target developers coming from OSX).  It's not for 
> *us* (except in as much as we are users of the code as well as its 
> maintainers).  So whether *we* are using a feature inside GNUstep has no 
> direct bearing on whether *we* support a feature ... the project is not 
> entirely self-referential ... the features we support are primarily for users 
> of GNUstep rather than for internal use by GNUstep.
> 
> Now, a user of GNUstep may want to use string literals and embed non-ascii 
> characters in them, and expect that when their application displays messages 
> based on those literal strings, the messages should be readable.
> We support this ... the base library takes the sequence of bytes embedded in 
> the binary by the compiler, interprets it as a UTF-8 string, and makes it 
> into an NSString object which the application is able to display in a 
> readable manner.
> But ... if the compiler embeds something in the binary which is not a legal 
> UTF-8 string than the end user will see rubbish or exceptions will be raised 
> in the app etc.
> So ... it makes sense for us to check that the compiler is doing the right 
> thing, and if it isn't, we need to warn the user to get them to use a 
> different compiler version or to make sure they avoid non-ascii literals or 
> take whatever other action is needed to ensure that only UTF-8 literals get 
> into the binary ... otherwise they will blame GNUstep for the run-time errors 
> caused by the compile-time failure.

Now, maybe we could do such a check at build time (ie have gnustep-make do it) 
rather than when we configure base ... not sure.  It would mean doing it every 
time we build anything, but it would mean that could accept any compiler which 
happens to work right in the current locale at the point when the compiler is 
actually being used ... more reliable.