On Sun, 11 Jun 2006, Ben Fowler wrote:
On 25/04/06, Michael Wybrow <mjwybrow@...1047...> wrote:
On Mon, 24 Apr 2006, Ben Fowler wrote:
A few weeks ago I mentioned that I had a small patch to the script (I think that it should delete incomplete bundles and images before starting the build operation), intending to ask for a review, ...
I'm probably the best person to look at the patch, since I've been the most heavily involved with writing/fixing the OS X packaging code.
Back in April, I was working on OS X packaging, and whilst not entirely back up-to-date, I have finished a substantial tranche on 'distcheck' and I am back on the osx-app.sh.
One thing that I don't understand is where the 'inkscape.mo' (locale) files come from. They are in your package, but not mine. I don't see them in the /usr/local/share directory or the build tree, they don't seem to be created by 'make install'. I think that I can see a rsync step that copies them into the bundle, but it appears to copy from a directory that I don't have.
Hidden in plain view!
Grateful for any hint as to where I should be looking oe what I should be doing to achieve the construction of this part of the bundle. Otherwise I think that I am doing O.K. at the moment.
Ben,
There were some problems with inkscape and particular combinations of the gettext mess in fink that caused the Inkscape configure script to think that it didn't have one of the necessary gettext functions available (dgettext). I spent some time looking at this problem but couldn't figure out what was going on. Possibly due to the fact that many fink pacakges (and fink selfupdate itself) used to swap gettext-dev and libgettext3-dev repeatedly. I was able to avoid the problem by setting ac_cv_lib_intl_dgettext=yes before running configure.
I no longer need this hack, and everything seems to work fine for me now using the 10.4 tree of fink and libgettext3-dev (the preferred one everyone is trying to switch to) to build Inkscape.
I think that there are some UI issues on the Mac - should I raise these now, or leave them till the next version?
I guess it depends on exactly what the problems are. Certainly they should be raised, though I don't imagine many more changes are going to make it in before the 0.44 release.
It would be nice to have a plan for a UB, but if this cannot be achieved in this release it might be best to leave it over and concentrate on matters that we know we can get done.
I think having a Universal Binary, or at least an Mactel version of 0.44 is *really* important. The later is a lot more feasible as it only requires someone with an Intel Mac to follow the existing packaging insructions and create a package. A Universal version will realistically require one of us Mac packager to have access to both a PPC and Intel Mac to sort out the process of creating Universal binaries, as well as testing early packages.
Cheers, Michael