Hi Blake,
thanks for your interesting and useful comments - and good patch. The
patch is good, but it's a hot issue. ;-)
I'm not sure what the solution is. I understand the obvious pros of
your patch,
but there are also some cons - I'll mention some. Ultimately we
probably just need to make it possible for each user to select their
preferred
linking behaviour (probably at ./configure time), and otherwise use
some default
behaviour that is the least surprising / clearly warns of anything
that might be
surprising. :-)
Anyway, I'll throw in some food for discussion first.
--
The main problem is that the "Apple way" of hardcoding the full
install path
of libraries and frameworks into the files themselves conflicts with
the standard
way of operating of gnustep-make. In particular, if we always do
this on Apple,
you get a different behaviour for gnustep-make between Apple and
other platforms,
which might be not be desirable ...
1. you then have to specify the installation domain when compiling
(eg, you have to type
'make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM') and you can't change it
when installing
(eg, you can't do 'make' then 'make
GNUSTEP_INSTALLATION_DOMAIN=SYSTEM') - else
it won't work. This would be very surprising for the average gnustep-
make user
coming from another platform. I suppose it could be acceptable, but
we really need
to print out clear warnings on Apple. ;-)
2. it means you can't move your library/framework from its final
installation dir;
this is different than what happens on all other platforms, and
could make packaging
more difficult (packaging usually installs things into a temporary
directory,
different from the one where things will be installed for real when
you install
the package) (I suppose that's not much of an issue if people are
using
whatever "Apple way" there is to package on Apple) - it can
certainly be confusing
for users coming from another platform. Maybe we can provide
instructions on changing
it after the installation.
Finally, after reading the Apple documentation on frameworks and
linking, I'm no
longer sure if we need to hardcode the path after all ... it may
depend on what
exactly you were trying to do :-)
I think the way it works is ...
1. you should really install your framework either in the standard
Apple filesystem
path (which requires no hardcoding of installation path), or bundle
it with your
application (which requires a custom install_name that you can set
manually using
DYLIB_INSTALL_NAME_BASE I think)
2. if you install it in a different ('private') location, then the
compiler/linker
can't find it unless you pass the appropriate flags - but if you're
building using
gnustep-make, then we do pass them when building an application - so
it should be
possible to build applications :-). Then the Apple documentation
says that the
applications store the full path of the frameworks, so it should be
possible to
then run the application even without gnustep-make and with no
special flags.
Unless we disabled storing the full path and only store a relative
one ?
That's quite possible, given our traditional dislike for hardcoding
full paths.
But in that case, we should probably look at the flags used when
linking an
application, and allow people/you to easily specify that they want
the full
framework paths to be stored in there ? That might be a better fix
(maybe) ?
Or maybe you were trying to distribute a framework installed in a
non-standard
location, and wanted people to be able to easily link it ?
Anyway, we'll definitely make whatever you want to do possible and
easy, but we
may want to have a ./configure switch to turn it on/off.
Comments welcome ;-)
Thanks for your time and help, much appreciated. Sorry if the issue
is a bit 'hot'.
-------
I plan to apply the following patch to gnustep-make, but would like to
see if anyone has any feedback against doing so first. The purpose of
this patch is to set the install_name on Mac OS X to an absolute
(rather than relative) path for libraries and frameworks. My reason
for doing this is that with the current gnustep-make, if you use a
file system layout other than apple on OS X, you will not be able to
launch applications from the Dock.
I see 3 different possible solutions to this problem (my suggested
patch is option 3):
1) Require any user on OS X to use the apple filesystem layout, and no
longer set DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH in GNUstep.sh
(neither one is necessary as all libraries and frameworks are put in
locations that are already searched when a filesystem of 'apple' is
used). For more info on why the apple filesystem layout works without
setting the DYLD environment variables, see:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/Articles/DynamicLibraryUsageGuidelines.html#/
/apple_ref/doc/uid/TP40001928-SW12
[http://tinyurl.com/anr4m]
and also
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/InstallingFrameworks.html#/
/apple_ref/doc/uid/20002261-97184-TPXREF101
[http://tinyurl.com/eogrc]
2) Allow users of OS X to use any filesystem layout, but gnustep-make
needs to create a ~/.MacOSX/environment.plist file to contain the same
environment settings as are set by GNUstep.sh. The environment.plist
file is necessary so applications launched from the Dock will have the
same environment (including DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH)
as applications launched from Terminal.
3) Apply my patch so that the install_name for libraries and
frameworks is absolute, rather than relative. This is by far the most
common way it is done on OS X 10.4 and 10.5 (I'm not sure about
earlier versions of the OS). In fact, I do not know of any public
libraries or frameworks that do it any other way.
Note that my patch does not prevent the use of
GNUSTEP_INSTALLATION_DOMAIN. The person building the library or
framework can still specify the domain and the install_name will be
set appropriately.
Please let me know if you see any problems with my patch or if you
recommend any adjustments to it. I am far from a gnustep-make master,
and appreciate any suggestions others may have.
Thanks,
Blake
Index: Instance/library.make
===================================================================
--- Instance/library.make (revision 26514)
+++ Instance/library.make (working copy)
@@ -236,9 +236,15 @@
LIB_LINK_VERSION_FILE = $(VERSION_LIBRARY_FILE)
LIB_LINK_SONAME_FILE = $(SONAME_LIBRARY_FILE)
LIB_LINK_FILE = $(LIBRARY_FILE)
-LIB_LINK_INSTALL_NAME = $(SONAME_LIBRARY_FILE)
LIB_LINK_INSTALL_DIR = $(FINAL_LIBRARY_INSTALL_DIR)
+ifeq ($(findstring darwin, $(GNUSTEP_TARGET_OS)), darwin)
+ # On Mac OS X, set install_name to the absolute path to the library
+ LIB_LINK_INSTALL_NAME = $(LIB_LINK_INSTALL_DIR)/$
(SONAME_LIBRARY_FILE)
+else
+ LIB_LINK_INSTALL_NAME = $(SONAME_LIBRARY_FILE)
+endif
+
#
# Internal targets
#
Index: Instance/framework.make
===================================================================
--- Instance/framework.make (revision 26514)
+++ Instance/framework.make (working copy)
@@ -307,8 +307,13 @@
ifneq ($(DYLIB_INSTALL_NAME_BASE),)
LIB_LINK_INSTALL_NAME = $(DYLIB_INSTALL_NAME_BASE)/$
(FRAMEWORK_FILE_NAME)
else
- # Use a relative path for easy relocation.
- LIB_LINK_INSTALL_NAME = $(GNUSTEP_INSTANCE).framework/$
(GNUSTEP_INSTANCE)
+ ifeq ($(findstring darwin, $(GNUSTEP_TARGET_OS)), darwin)
+ # On Mac OS X, set install_name to the absolute path to the
framework
+ LIB_LINK_INSTALL_NAME = $(LIB_LINK_INSTALL_DIR)/$
(GNUSTEP_INSTANCE)
+ else
+ # Use a relative path for easy relocation.
+ LIB_LINK_INSTALL_NAME = $(GNUSTEP_INSTANCE).framework/$
(GNUSTEP_INSTANCE)
+ endif
endif
_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev