bugGNUstep - Bugs: bug #12575, suggestion about header files in...

Group
 
 

bug #12575: suggestion about header files in frameworks

Submitter:  Wolfgang Sourdeau <wolfgang>
Submitted:  Wed 06 Apr 2005 03:04:33 AM UTC
   
 
Category:  Makefiles Severity:  3 - Normal
Item Group:  Change Request Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 08 Apr 2005 10:10:20 AM UTC, comment #4: 

-framework in gcc is a snap to implement, it only sends -framework to ld, this is in gcc 4 already but only enabled for darwin in gcc/config/darwin-c.c. (only -F is needed for the header lookup)

ld support is blocked by ld.so support search for 'slash' in
http://www.caldera.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies

ELF defines semantics which conflict with framework support, and my requests/patches for a substitution sequence (next section below the reference to slash) which would produce an undefined behaviour by the ELF spec where we could implement what is needed for frameworks, have fallen on deaf ears.

anyhow i have it all working, what is left seems mostly political.


matt rice <ratmice>
Group Member
Fri 08 Apr 2005 02:58:33 AM UTC, comment #3: 

Thanks for your (quick) answers!

Regarding the file-hierarchy, it makes sense after what you told me. I supposed we should wait for GNU GCC to have support for the -framework flag, which should not be very difficult to implement... Any idea of why it's not the case?


Wolfgang

Wolfgang Sourdeau <wolfgang>
Wed 06 Apr 2005 12:05:49 PM UTC, comment #2: 

Having looked into that again, I think we don't need to change the header structure because you can already access the framework headers as required by using ...

-I<path to the framework build dir>/derived_src

derived_src already contains the headers in the form <name>/<header> so that by using -I<path to the framework build dir>/derived_src you should be able to use the framework headers in other parts of the same project.

Eg, if you have

MyFramework
MyApplication

and you compile MyFramework before MyApplication, you can access MyFramework's headers from MyApplication by adding

-I../MyFramework/derived_src

#include <MyFramework/MyHeader.h>

That should work well :-)

Thanks for your feedback!  Much appreciated :-)

Nicola Pero <nico>
Group Member
Wed 06 Apr 2005 11:26:59 AM UTC, comment #1: 

Thanks - this is a very interesting suggestion. :-)

I believe the reason we have directory structure that we currently have is that it was chosen to be similar / the same to the Apple one ...

... but I suppose we could think of changing it ...

Hmmm.

Nicola Pero <nico>
Group Member
Wed 06 Apr 2005 03:04:33 AM UTC, original submission:  

The current filesystem infrastucture for frameworks is a follows:

[name].framework/Headers -> Versions/Current/Headers
[name].framework/Resources -> Versions/Current/Resources
[name].framework/Versions
[name].framework/Versions/A
[name].framework/Versions/A/Resources
[name].framework/Versions/A/Headers
[name].framework/Versions/Current -> A
[name].framework/Versions/A/[name] -> lib[name].so
[name].framework/Versions/A/lib[name].so -> lib[name].so.[version]
[name].framework/Versions/A/lib[name].so.[M] -> lib[name].so.[version]

Considering the current support for the -framework flag in gcc, this seems reasonable. However, when one wants to emulate this flag for an aggregate project where some elements depend on a previously built framework that's part of the same project, it becomes tricky to refer to the correct location for the framework  headers.

We know that framework headers will always be referred to with "<[name]/[header].h>" in the source files. So it would only make things easier of the generated .framework bundle would respect that too and have /Headers/[name] instead of /Headers alone.


Wolfgang Sourdeau <wolfgang>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follows 1 latest change.

Date Changed by Updated Field Previous Value => Replaced by
2005-04-06 nico Open/ClosedOpen Closed

Back to the top

Powered by Savane 3.13-4448.
Corresponding source code