bugGNUstep - Bugs: bug #12576, alternative to the...

 
 

bug #12576: alternative to the "-framework" flag

Submitted by:  Wolfgang Sourdeau <wolfgang>
Submitted on:  Wed 06 Apr 2005 03:09:26 AM UTC  
 
Category:  Makefiles Severity:  3 - Normal
Item Group:  Change Request Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 08 Apr 2005 03:08:13 AM UTC, comment #4: 

Hi again,

The reason why I use -rpath is because it's the only way for me not to install my framework before running my application. That's a personal choice, based on my personal way of doing things. But if you look a bit further on the same line, the "-l" flag is used.
Therefore, if the library is not found in the defaut place (-rpath), it's searched in the regular library paths.

I just tested it and it works.

Regarding the scanning of directories. It does not happen every time a file is compiled. It happens only when the ADDITIONAL_CFLAGS and ADDITIONAL_LDFLAGS are computed in the makefile. However, your commentary made me realize that I omitted  the default system frameworks directories (which is not difficult to do). Actually, all the cryptic make code you can read there is meant to reduce the search path of GCC. I do this by checking that all the mentionned frameworks dirs do exist (using 'wildcard').

Wolfgang

Wolfgang

Wolfgang Sourdeau <wolfgang>
Wed 06 Apr 2005 11:34:17 AM UTC, comment #3: 

not sure if apple does that, they may do that, but otherwise 'relocatable frameworks' are also supported, which basically link to a path relative to the search path. which you can set through DYLD_FRAMEWORK_PATH

matt rice <ratmice>
Project Member
Wed 06 Apr 2005 11:12:32 AM UTC, comment #2: 

Sorry, the last comment was from me.

Thanks

Nicola Pero <nico>
Project Member
Wed 06 Apr 2005 11:11:07 AM UTC, comment #1: 

Thanks for your contribution! :-)

It might help some people who might want to use the same code ...

As for the general gnustep-make setup, our current solution is probably better.  The symlinks work very well on Linux.

In the proposed patch, you are using the -rpath option to the linker to hardcode the path to the framework inside the compiled executable.  The problem with this is that it means if you have a framework in System root, compile your application, then deploy the .app file to another machine where the framework is installed but inside Local root, the application stops working.  The same would happen also if on the other machine the location of the System/Local/Network/User roots change!  This is obviously unacceptable; a framework installed in any of System/Local/Network/User root should be immediately usable by any application needing that framework, no matter where System/Local/Network/User are located on that machine.

We do not want to hardcode paths to frameworks/shared libs anywhere.  I think Apple does that; it's a really bad habit they have, and they get away with it just because they control their system so tightly that most stuff can only be installed in a single place.  In the case of Linux, different people tend to install things in different locations, and GNUstep should be enough robust not to go mad if a framework is moved from Local to User for example.

Btw I can't generally see the advantage of the patch ... you're getting away without having to create symlinks in the shared libs directory, but then you can't move your framework (or your framework directories) anywhere without breaking the stuff.  You can't run your binary on another machine where the frameworks are located in a different place on disk ... so it's a regression compared to the current symlink solution!

I'm also a bit uneasy about scanning large number of directories on disk to search for frameworks every time a file is compiled.  The standard shared libs system with all the shared libs in a single directory makes for reasonably efficient compilation.

Thanks

Anonymous
Wed 06 Apr 2005 03:09:26 AM UTC, original submission:  

Here enclosed, the makefile I include in the (sub)projects's GNUmakefile that requires to be linked to some frameworks.

The syntax to use is as follows:

FRAMEWORKS_DIRS = /whatever/absolute/path/Frameworks ../relative/works/too/but/will/be/converted/Frameworks
FRAMEWORKS = MyFramework YourFramework

including that file will automatically adjust ADDITIONAL_INCLUDE_DIRS and ADDITIONAL_LDFLAGS with computed flags.

Wolfgang Sourdeau <wolfgang>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #2843:  frameworks.make added by wolfgang (469B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

 

 

Follow 2 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-04-06 nico Open/ClosedOpen => Closed
2005-04-06 wolfgang Attached File- => Added frameworks.make, #2385

Back to the top


Powered by Savane 3.6