Re: Compilation error on Solaris...

[Richard Frith-Macdonald]

On 29 Apr 2010, at 08:35, Fred Kiefer wrote:

> Am 28.04.2010 22:56, schrieb Gregory Casamento:
>> I'm pleased to report that deleting the version of GNUstep I had at
>> /usr/GNUstep cleared this problem.  It's likely an issue with
>> includes.  It appears the code may be including the .h files from the
>> installed version rather than the one we're building from when the
>> installed version is available (am I describing this clearly?).
>> 
>> I would still consider this a bug, albeit a minor one.   Also, with
>> the version of GCC I'm using, gcc 4.3.x, I'm getting a message about
>> missing stdint.h.  It's been a while since I built on Solaris, so I'm
>> not sure if this is expected.
> 
> The problem you had was with a gui file (NSGraphicsContext.m)  including
> a base header (NSThread.h). I think in this case of two different
> libraries, although belonging to the same project, we would expect that
> the installed files get used in preference over any other version.
> Within the base library Richard tried to address the import issue by
> changing all import in implementation files to use "" when importing
> headers from the same library and started to use some #ifdef mechanism
> in the headers to achieve the same there:
> 
> #if   defined(GNUSTEP_BASE_INTERNAL)
> 
> At the moment this isn't used in all base headers (and gui still lags
> behind, there we only have cleaned up most of the implementation files).
> What I don't see is how this mechanism could have helped in your case.

Agreed ... it seems to me that it is correct behavior for gui to build using 
the *installed* base library.

When building base, base should use its own headers, not the installed ones.
When building gui, gui should use its own headers, not installed ones, and so 
on.

But gui should use the installed base headers, and back should use installed 
base and gui headers.
That's because base, gui, and back are all separate packages.

Now, it might be nice to be able to build a core package entirely standalone 
without reference to installed headers, but I think that's a special case we 
haven't addressed ... it would presumably need a mechanism to tell gnustep-make 
to refrain from looking for installed headers (eg by supplying a special 
version of GNUstep.conf and using the environment variable to get it used 
instead of the default one).