gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GCC Framework support in Linux (fwd)


From: David Ayers
Subject: Re: GCC Framework support in Linux (fwd)
Date: Wed, 13 Aug 2003 19:42:44 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

Adam Fedor wrote:

On Monday, August 11, 2003, at 03:24 PM, Stefan Urbanek wrote:


Pershaps we should begin with explicitly answering few, even some of them with obvious answers, questions:

1. What are the differences between GNUstep and Applie framework structure?
2. How to find a binary or headers in a framework?
3. What are the differences for standard framework locations in GNUstep and Apple?
4. How to specify frameworks and their locations? (-f -F)
5. How to tell gcc which GNUstep combo to use for searching executable? (if it is necessary at all)
6. ...

I think it is probably a good start to answer these questions.

After Adam tried to shed some light into this, Apple developers posted some information on how thier frameworks should work on gcc's lists:

http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00738.html
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00753.html

It seems clear that whatever the current semantics for framework support in FSF compiler tool chain is, it is far away from Apple's compiler tool chain. I guess we should get involved, as Stefan already tried, to bring some portability aspects into this discussion. We should try to merge the Apple / FSF semantics of frameworks which seem to be reflected in compiler, linker and loader while taking into account the library-combo and target specific Headers and binaries.

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.

Anyway, independent of this I think the our current header structure for "standard" library headers are unaffected by frameworks*. That structure discussion is only relevant disable-flattened, and it's a simple tradeoff between installing multiple headers and reducing -I flags (due to extra indirection needed for non-*-gnu-* libary combos. I think it was previously pointed out at multiple occasions and once shortly before the switch:

http://mail.gnu.org/archive/html/gnustep-dev/2003-07/msg00101.html
http://mail.gnu.org/archive/html/gnustep-dev/2003-07/msg00102.html

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 :-))

Cheers,
David

* They are affected in the sense that the current links generated for frameworks from the target/library specific headers directories all point to same framework header directory





reply via email to

[Prev in Thread] Current Thread [Next in Thread]