Re: GCC Framework support in Linux (fwd)

[David Ayers]

Adam Fedor wrote:

> On Wednesday, August 13, 2003, at 11:42 AM, David Ayers wrote:
>
> > It's just too ironic that this is happening while Nicola is away.  
> > I'm not sure if a could lead a meaningful discussion on the gcc list 
> > about this.  But unless someone else jumps in, I'll take a shot at 
> > it.  I think argumenting for target specific handling might be 
> > accepted, but I don't know how we should approach the concept of 
> > library-combos as this will most likely be viewed as an arbitrary 
> > selection frameworks/libraries to add extra handling for which is 
> > only meaningful in the context of OpenStep and ObjC runtime's.
> We should probably chime in, just so they know we are interested. 

I still haven't looked closely at the changes yet.  I'm still a bit 
boged down with other GCC issues.  (And I know there are also GDL2 
issues piling up.)  But I'm not convinced we have a consensus yet on the 
issue itself.  What are we interested in?  Do we simply request for the 
same semantics Apple is proposing plus platform specific handling?  Or 
potentially hooks for arbitrarily selecting the library at load time 
(libcombo issue)?  I now that other GNUstep developers agree with Niel 
Booth that most of these issues should remain Darwin specific for now.  
Personally I'm uneasy about incompatibilty without due reason, but 
that's personal gut feeling, as sometimes follwing Apple in the wrong 
direction can be costly.

> > I'm not really sure whether the Headers really need to be installed 
> > in library combo specific directories for any other reason than the 
> > -I flags, that couldn't be resolved with #ifdef's but as that would 
> > only affect -make and those header internals, so I'm not too worried 
> > if we decide to change it again, even though we would "recomplicate" 
> > -make.  It would be nice though if the issue could be resolved once 
> > and for all before we release again.  (Deja vu :-))
>
> I though the most useful part of putting headers into a 
> target-specific dir was versioning - e.g. I have gnustep-base 
> installed on two targets. Then I upgrade one target (perhaps a 
> development version), and I don't want those headers screwing up the 
> other (perhaps stable) target.

Very true.  Actually while we're pondering about this, maybe we should 
also consider our special extensions for debug and profile versions of a 
library.  I think that some mechanism to optinally turn of the special 
extensions would be really nice and probably should be dafault.  I spend 
a lot of time syncing up version after I finnally noticed that that 
either one or the other library wasn't actually up to date.  (I'm not 
talking about apps, but shared libraries especially.)

> With frameworks, that's not really as important since they have 
> versioning built in. I think it does complicate things a bit much 
> however, that's why I think we should reconsider it.

Also very true, but the versioning of frameworks (when it comes to 
headers) is not supported by our current mechinsm which relies on 
creating symlinks in the top Headers/ directory., independant of version 
or target.  But I I agree, the libcombo specific versioning could be 
made obsolete for framework headers, if/once the support for framework 
is in the tool chain, including target specific handling. 

Cheers,
David