[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: building a self-contained deployable gnustep
From: |
Richard Frith-Macdonald |
Subject: |
Re: building a self-contained deployable gnustep |
Date: |
Thu, 13 Oct 2011 12:02:55 +0100 |
On 13 Oct 2011, at 11:32, David Chisnall wrote:
> I have some out-of-tree patches that make this quite easy - I wrote them for
> deploying on WebOS, where I wanted to do the same thing. I hope to have time
> to tidy them up (and make sure that they don't break other configurations)
> soon...
>
> Basically, you can link the GNUstep libraries just as you would others, but
> they need to be able to find the their resources. There is some optimisation
> in NSBundle that, unfortunately, has the side effect of breaking everything
> when the GNUstep libraries are not where they expect to be. This primarily
> means that the time zone data is not in the right place.
>
> I'm not 100% certain why the time zone data needs to be bundled with GNUstep,
> since it's present on most systems anyway, so I also want to look at
> factoring this out a bit.
You've never read the comments in the timezone code then :-)
Generally speaking there's no reason we can't work with system time zones where
available, but system time zones are not standard ... using our own means we
can be more OSX compatible.
Anyway, while gnustep-base has not actually depended on any external resource
files for a few years, that's not the case for gui and for other applications
etc which expect to use standard APIs to find resources in standard locations.
That's why gnustep-make has configurable layouts to say where to find things,
and gnustep-base has configurable options to make all those layouts relative to
the base library ... so as long as your code can link to the base library, you
can set up a relocatable, standalone package where everything just works.