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/ local-universal-macports-in-really-long-prefix-for-inkscape-etc-etc... 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.
Cheers, Michael