On 01/09/2009, at 10:15 AM, Michael Wybrow wrote:
> On 31/08/2009, at 6:11 PM, Alexandre Prokoudine wrote:
>> Sorry for pushing, but it's a week since pre2 was released and all we
>> have is sources :(
> Anyway, Mac builds are coming and haven't been forgotten. If anyone
> else with mac packaging experience wants to contribute to the effort,
> it would be useful to look at some of the outstanding issues I haven't
> got to yet, like the dictionary bundling or the DBUS bundling/startup
> (might be similar to what GIMP has). If so, let me know.
I've put up a Mac Inkscape-0.47pre2-1.LEOPARD.dmg package. I wasn't
able to add it to the existing 0.47pre2 directory on SourceForge (same
problem the Windows packager had) because there were no group write
permissions on that directory. Hence I renamed that directory to
"UnwritableDir" and made a new 0.47pre2 directory and copied all the
0.47pre2 files there. Can someone remove the UnwritableDir
directory? Also, can whoever creates such release folders in future
please check that they are writable by other inkscape packagers?
I'll test this package on Snow Leopard tonight, but it should
hopefully work given I tried some earlier private builds.
For any of the Mac packagers (not important for users themselves),
this build includes the ImageMagick components that were previously
missing, thanks ~suv. Note: the ImageMagick components will fail if
the user has a version installed in the same prefix that the packager
used when building the bundle -- this is a good reason to use an
obscure long Macports prefix if you're packaging (see next
paragraph). This is because you can tell ImageMagick where to look
for its components but it still checks it's install directory and uses
them anyway if they exist.
Also, it the package no longer uses the DYLD_LIBRARY_PATH environment
variable to specify where the libraries can be found. Instead they
all have their internal paths rewritten at packaging time to be
relative to the path of the executable. To allow enough space in the
libraries and executables for this path rewriting, the packager must
use a Macports installation that has been installed in a longer than
normal PREFIX. I don't know what the minimum size is, but I've put a
requirement in the packaging script to check that it is at least 50
characters. Thus it needs to be installed in something like /opt/
you get the idea. This should solve a lot of problems with our
bundled libraries conflicting with system versions.
I haven't yet looked at the aspell issue.
Let me know of any new issues.