On 01 Jul 2006, at 14:15 , Ben Fowler wrote: That is true and to compile Inkscape on OS X you need Fink unstable anyway and hence you have: gtk+2 2.6.10-1001 gtkmm2.4 2.6.4-1001 I sent an email to the maintainers of GTK packages in Fink to have an idea of their schedule. It might be pretty long term given that the team maintains all gnome packages in Fink. I'll give update as soon as I receive news from them. JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/

On 01/07/06, jiho <jo.irisson@...400...> wrote: Hmm. (Quick work BTW). Like the basic fink plan, I have been avoiding /sw and /usr/local for installing libraries that I have built myself. (I use /jaguar , /panther ). My original point was that we may need to plan on nothing much happening in the near future or indeed at all. If we can have the luxury of planning, we really need 2.10; and it would be by far the best if the fink team could deliver that. If not, what would be the possibility of one of us producing the packages we really need, gtk, gtkmm and sigc++ for fink unstable. Would this have an adverse effect on the fink project? Would there be a burden of maintenance/security patches that would make this impossible. If nothing is done then we might end up having to label some of these libraries as 'fourth party' (fink being the third party) and install them in /inkscape perhaps needing to place these versions in our svn. What about Universal Binaries? I dread to think what the instructions for building Mac Inkscape will look like ... Ben

On 01/07/06, jiho <jo.irisson@...400...> wrote: I had always imagined that we provide the source, and the fink team could create their X11 (Gnome or KDE) packages as .deb if they wished. They know their methods ... ... It doesn't sound at all viable, more that just 'difficult'. Why not? This is what the Firefox people do with third party libraries such as svg and cairo. They don't use any fink libraries, and the nearest thing that I can think of is a 'Shared Menus' framework which builders need to copy to one of their 'Library' folders. We could do that. Provide either a pre-built gtk/gtlmm/sigcc+ set of frameworks (or the XCode projects to create them), and have builders install those. The build process for Inkscape would copy these Frameworks into the .app bundle. I hope that this doesn't come across the wrong way, but I don't think any of that is quite consistent with what we have been saying. 1. The question of which version of Gtk to require cannot be taken by either of us. The team as a whole or the leaders need to state whether a version later than 2.6 is required, if the answer is 'Yes", then it is up to us to solve the problems in some way. Even if the answer isn't a definite "Yes', then we are only putting off the evil moment, because I can't see that the fink project is going to overtake us anytime soon. It is obvious to me (though I might be wrong) that a project like Inkscape really does require recent code with the fixes and interface ideas. If you really want to be a 'a last ditcher', then the best that I can see would be to defer up-rating the requirement until this Autumn and then go straight to 2.10 . 2. I really don't want to speak of only a handful of people actually compiling Inkscape. We are a community and there is no reason why Mac users in large numbers should not be compiling it. Part of the raison d'être of any open software project is to offer training, and support in collaboration with other developers and working with a large codebase. Telling our community to accept .dmg is not in any shape or form an attractive option! This would detrimental both to bug fixing and working with new features. 3. The sourceforge statistics show the Mac deliverables being downloaded in large numbers - now I think that this is because the label for the Universal.dmg makes it look as though it is a combined Mac/Windows/Linux thingy, and I suspect that many people who do download it have to come back to download the Windows version that they actually wanted. Even so we should be encouraging people to get invoved with development, not creating a charmed circle or clique for people who have mastered the art. 4. It only makes sense if we knew that there will be a fink set of libraries in the medium term, and I think that the reverse applies! We would do better waiting to see which libraries Apple ship with Leopard! (I'm talking past you here, sorry). What I meant was: Is it not the case that the fink libraries have no support for Universal Binaries? If so, I think that we have to take a decision to cut adrift from the fink project (as an interim measure) this summer, that is, as of now; because I thnk that we do need a one-step way of building Universal Binaries. Note that I don't have strong feeling concerning the 'what' of what we do, but I do feel that the 'how' of how do we move on from 0.44 to 0.45 is important! Ben.

On Sun, 2 Jul 2006, jiho wrote: No, it is not yet automated. But I will cleanup the script I've been using and add it to SVN soon. How it is done is to take two complete release .dmg packages, each built on a different architecture type (x86 and ppc). These need to be built on machines that have the same set of fink packages installed. Then, you put the two .app trees in a directory and name them Inkscape_x86.app and Inkscape_ppc.app. Next you copy one of those, naming it Inkscape.app (the universal one). After that, you run through all the files that differ between the x86 and ppc tree, checking they have all the same set of files, and if they are .dylib, .a, .so, or executable files, then run lipo to create a universal version of them: lipo $INTEL/$FILE $PPC/$FILE -create -output $UNIVERSAL/$FILE Then check the process worked! I aggree with needing a one-step way of building Universal Binaries. The way we're doing it is phone to errors and requires a lot of checking--it is really a short-term solution. If anyone is going to investigate building GTK 2.8 and all its dependencies outside of fink, then that would be a good time to try configuring and building all of them as universal. Cheers, Michael

As I've been saying for a while, we should ship Inkscape bound -statically- to the C++ libs we need, so that there will not be a dependency on -them-. The binary will be larger, of course, but the memory footprint would be the same as when you launch dynamically-bound Inkscape, and the C++ .so's need to be loaded. Our problem would be with how the C++ libs work with the corresponding Gtk libs. But this would be the same as how Inkscape would depend on Gtk, anyway. This also helps to save us from C++ ABI mismatch problems. So what you would do is start from gtkmm source, and the normal Gtk libs that Fink has, and build gtkmm statically. ./configure --disable-shared --enable-static not only builds the libxxx.a files, but also configs the libtool .la files in the lib directory. bob

On 01 Jul 2006, at 19:12 , Joshua Blocher wrote: I am eagerly waiting for these but have not seen anything new since the announce that GTK code for OS X was merged to GTK trunk, a few months ago. I guess that when Gimp will compile and run natively on OSX (it actually compiled a while ago but still does not run), things could start for Inkscape. I am probably not the best person to give this estimate but I guess this is even longer term plans that Fink updating to GTK 2.8 (unfortunately...) Not completely in fact because Inkscape depends on many other libraries from Fink. Currently, GTK might be the limiting factor but libgc is not far form being limiting too. Honestly I will prefer avoiding to switch to GTK 2.8 ;-) but not switching to 2.8 will be for the comfort of few (as I mentioned, there should be around 4 people compiling Inkscape on OS X) and will annoy many others (users and developers needing the functionality in GTK 2.8). JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/

On Sat, 1 Jul 2006, jiho wrote: I asked the GTK fink people the same question a while ago when the idea of depending on 2.8 was pitched. I recieved a similar reply that it was a big dependency mess and it was all too hard. One of the major problems is needing to move to a new non-apple version of freetype. Which makes things a real mess. The following statment from Daniel Macks gave me a little more hope: | Freetype claims that 2.2 has reverted to compatibility with pre-2.1.9. | Breaking binary compatibility is the only reason 2.1.9 has to be a | separate package with files in weird locations and not just a new | version of the pre-existing freetype2 package. So we need to verify | that nothing has changed or been removed from the public interface of | freetype going from 2.1.4 to 2.2.1. | | If that's true, we can probably upgrade freetype2 to 2.2.x, and ignore | freetype219 and its nightmare entirely. That would mean we could | easily upgrade things that require the newer freetype. | | Which still leaves cairo. Here's the last time I rambled on about its | issues: http://article.gmane.org/gmane.os.macosx.fink.devel/12484 So I guess the first thing to do would be look at the freetype compatibility issue. The quoted link describes the dependency problems of this change quite well. Does seem like a lot of work. Cheers, Michael