[Top][All Lists]

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

[bug #12576] alternative to the "-framework" flag

From: anonymous
Subject: [bug #12576] alternative to the "-framework" flag
Date: Wed, 6 Apr 2005 11:11:07 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Follow-up Comment #1, bug #12576 (project gnustep):

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.



Reply to this item at:


  Message sent via/by Savannah

reply via email to

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