Re: Is GNUstep Examples maintained?

[Richard Frith-Macdonald]

On 21 Aug 2013, at 08:19, David Chisnall <theraven@sucs.org> wrote:

> On 21 Aug 2013, at 08:03, Richard Frith-Macdonald 
> <richardfrithmacdonald@gmail.com> wrote:
> 
>> I haven't spoken up before because I have no particular knowledge of most of 
>> what you mention, but I do know that the Performance framework builds fine 
>> with the latest release (and with trunk) on several platforms.  So if it's 
>> not building for you then that must be with some specific unusual setup.
> 
> The errors I see are:
> 
> Compiling file GSCache.m ...
> GSCache.m:503:1: warning: conflicting distributed object modifiers on return
>      type in implementation of 'release' [-Wdistributed-object-modifiers]
> - (void) release
> ^  ~~~~
> /usr/local/GNUstep/System/Library/Headers/Foundation/NSObject.h:180:1: note: 
>      previous declaration is here
> - (oneway void) release NS_AUTOMATED_REFCOUNT_UNAVAILABLE;
> ^         ~~~~
> GSCache.m:773:17: warning: incompatible pointer types assigning to 'NSLock *'
>      from 'NSRecursiveLock *' [-Wincompatible-pointer-types]
>  allCachesLock = [NSRecursiveLock new];
>                ^ ~~~~~~~~~~~~~~~~~~~~~
> /usr/local/GNUstep/System/Library/Headers/Foundation/NSObject.h:363:1: note: 
>      class method 'new' is assumed to return an instance of its receiver type
>      ('NSRecursiveLock *')

I'm not sure if the first two are compiler bugs?
As I recall the DO type qualifiers like oneway are required in the interface 
but not in the implementation.  Maybe that's a language change for objc2?
And assigning a derived class instance to a variable types as the base class is 
definitely legitimate/normal.

Anyway, I susppse we can twek things to make the compiler happy even if it's a 
false alarm

> + (id) new;
> ^
> GSCache.m:857:32: warning: direct access to Objective-C's isa is deprecated in
>      favor of object_getClass() [-Wdeprecated-objc-isa-usage]
>  return class_getInstanceSize(isa); 
>                               ^
> /usr/local/GNUstep/System/Library/Headers/Foundation/NSObject.h:293:9: note: 
>      instance variable is declared here
>  Class isa;
>        ^

That's easy.

> GSCache.m:913:16: error: use of undeclared identifier 'content'; did you mean
>      'cgetent'?
>      size += [content sizeInBytes: exclude] + [headers sizeInBytes: exclude];
>               ^~~~~~~
>               cgetent
> /usr/include/stdlib.h:262:6: note: 'cgetent' declared here
> int      cgetent(char **, char **, const char *);
>         ^
> GSCache.m:913:16: warning: receiver type 'int (*)(char **, char **, const char
>      *)' is not 'id' or interface pointer, consider casting it to 'id'
>      [-Wreceiver-expr]
>      size += [content sizeInBytes: exclude] + [headers sizeInBytes: exclude];
>               ^~~~~~~
> GSCache.m:913:49: error: use of undeclared identifier 'headers'
>      size += [content sizeInBytes: exclude] + [headers sizeInBytes: exclude];
>                                                ^
> GSCache.m:926:16: error: use of undeclared identifier 'name'
>      size += [name sizeInBytes: exclude]
>               ^
> GSCache.m:927:12: error: use of undeclared identifier 'value'
>        + [value sizeInBytes: exclude]
>           ^
> GSCache.m:928:12: error: use of undeclared identifier 'objects'
>        + [objects sizeInBytes: exclude]
>           ^
> GSCache.m:929:12: error: use of undeclared identifier 'params'
>        + [params sizeInBytes: exclude];
>           ^
> 4 warnings and 6 errors generated.
> 
> They appear to be because it is directly accessing ivars that are not public 
> and not exposed from a category on GSMimeDocument (in the first instance, 
> I've not checked the subsequent ones).  If these ivars are expected to be 
> used outside of the GNUstep Base Framework, then they should not be hidden.  
> If they are not expected to be used outside of the GNUstep Base Framework, 
> then the Performance framework has a bug that only shows up with the 
> non-fragile ABI.
> 
> It fails after the first file, so I've not see what subsequent errors appear. 
>  

Yes, the main part of this seems to be use of @defs which is no longer 
supported with the non-fragile ABI (for obvious reasons).  I guess this must 
never have worked for non-fragile setups.
So why does it build for me on my clang-3.3 based system?  Guess I need to look 
at what compiler flags are being passed.