|
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.htmlIt 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.htmlI'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
[Prev in Thread] | Current Thread | [Next in Thread] |