[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-make on OSX
From: |
Helge Hess |
Subject: |
Re: gnustep-make on OSX |
Date: |
Mon, 23 Dec 2002 18:58:15 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 |
Nicola Pero wrote:
Here we are really talking about something different - it's that the
bundle structure of NeXTstep is different from the bundle structure of
GNUstep which is different from the bundle structure of Apple OSX.
OK, I see the point now ;-)
:-) Is there already something new for OSX in CVS ?
I'm now actively thinking. :-)
Excellent ;-)
But then, I can see the following problem - if you write an application
which depends on this library/framework, on GNUstep you would write
ADDITIONAL_GUI_LIBS += -lRenaissance
while on OSX if Renaissance is a framework, you would need
ADDITIONAL_GUI_LIBS += -framework Renaissance
Maybe the solution would be to have the conversion done automatically by
gnustep-make, or to use a new variable name and have gnustep-make add the
-l on gnustep, and the -framework on OSX.
This is tricky, you are right. But couldn't which_lib easily process
this information (take a look whether a MyLib.framework exists) ?
BTW: in OSX you can bundle frameworks in any bundle. Eg for
distribution you can add all required frameworks into the application
bundle. All this makes it very easy to install apps for the user.
>
Hmmmm. Ok.
Well, as a personal comment, except for the resources, this is basically
statically linking the application to all the libraries it depends upon,
which generates very big executables. Very easy to install, but very big.
There are some things to consider:
a) probably the bundled frameworks are usually "private" frameworks. Eg
in OmniWeb there is the networking code, the HTML rendering framework,
the ... - all this isn't really used by any other application. In this
case this really is just a packaging thing - the developers separates
the stuff to separate things during development and the user can install
a single wrapper.
b) do we have a harddisk space issue ? IMHO not. I don't care whether
the .app takes 1MB or 10MB, doesn't matter these days ;-)
c) do we have a memory problem ? This is an interesting one. I wonder
whether the MacOSX dynamic linker does use the path for linking or
whether it can share frameworks based on the versioning information and
on the name ? Maybe Marcel nows about that one ?
I frankly prefer a lot more the package manager way of linux lands, which
installs (and uninstalls!) applications and shared libraries properly,
manage dependencies between things etc. :-)
Very good too (you know I *like* RPM ;-), but OSX doesn't have that. I'm
talking about using gstep-make on OSX, and this probably should include
that (OSX) way of packaging things.
Greetings
Helge