Re: [Inkscape-devel] Versions of gtk/gtkmm used by distros?
----- Forwarded message from Denis Leroy <denis@...1381...> -----
Date: Sun, 25 Jun 2006 14:56:40 -0700 From: Denis Leroy <denis@...1381...> To: gtkmm-list@...1382... Subject: Re: Versions of gtk/gtkmm used by distros?
Bryce Harrington wrote:
Hi,
For Inkscape we're considering changing our required gtk/gtkmm requirements from 2.4 to something newer (e.g. 2.8).
Could someone point me at a listing of which distros ship with which version of gtk? We're attempting to gauge how many users would be affected by this change.
Speaking for Fedora :
Fedora Core 3 (unmaintained) : 2.4.11 Fedora Core 4 : 2.6.5 Fedora Core 5 : 2.8.3 Fedora Core 6 test 1 : 2.8.5
-denis _______________________________________________ gtkmm-list mailing list gtkmm-list@...45... http://mail.gnome.org/mailman/listinfo/gtkmm-list
----- End forwarded message -----
On 26/06/06, Bryce Harrington <bryce@...961...> wrote:
----- Forwarded message from Denis Leroy <denis@...1381...> -----
For Inkscape we're considering changing our required gtk/gtkmm requirements from 2.4 to something newer (e.g. 2.8).
Mac OS X - fink has 2.4.9 in stable; anything more recent that 2.6.10 will cause disruption, I fear.
You might want to see whether Michael Wybrow comes up with anything.
FWIW, whilst is developer-friendly to set one's requirements for dependenices to be say a year or two back, if it is known that Inkscape really does need these recent versions then we should simply announce the fact and accept the pain.
Ben
On 01 Jul 2006, at 14:15 , Ben Fowler wrote:
On 26/06/06, Bryce Harrington <bryce@...961...> wrote:
----- Forwarded message from Denis Leroy <denis@...1381...> -----
For Inkscape we're considering changing our required gtk/gtkmm requirements from 2.4 to something newer (e.g. 2.8).
Mac OS X - fink has 2.4.9 in stable; anything more recent that 2.6.10 will cause disruption, I fear.
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.
You might want to see whether Michael Wybrow comes up with anything.
FWIW, whilst is developer-friendly to set one's requirements for dependenices to be say a year or two back, if it is known that Inkscape really does need these recent versions then we should simply announce the fact and accept the pain.
Ben
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel? cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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 Jul 2006, at 14:38 , jiho wrote:
On 01 Jul 2006, at 14:15 , Ben Fowler wrote:
On 26/06/06, Bryce Harrington <bryce@...961...> wrote:
----- Forwarded message from Denis Leroy <denis@...1381...> -----
For Inkscape we're considering changing our required gtk/gtkmm requirements from 2.4 to something newer (e.g. 2.8).
Mac OS X - fink has 2.4.9 in stable; anything more recent that 2.6.10 will cause disruption, I fear.
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.
Here is the answer I received from Fink GTK packages maintainers.
Begin forwarded message:
From: "Benjamin Reed" <rangerrick@...400...> Subject: Re: [gnome-core] Schedule for GTK 2.8 in fink?
On 7/1/06, jiho <jo.irisson@...400...> wrote:
[...snip...] gtk+2 and gtkmm2.4 are at version 2.6.4 in Fink unstable. I was wondering about the schedule of the integration of version 2.8 in Fink (given that 2.10 should be out shortly). [...snip...]
To be honest, I think mostly people are afraid to touch it. :)
I think what it will need is a concerted effort to hack up all of the gtk-using packages to be updated (in the manner we did to move to the 10.4 tree) and get everything moved at once.
so it seems i nothing will happen in the near future :-)
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:
On 01 Jul 2006, at 14:38 , jiho 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.
Here is the answer I received from Fink GTK packages maintainers.
[...snip...] I was wondering about the schedule of the integration of version 2.8 in Fink (given that 2.10 should be out shortly). [...snip...]
To be honest, I think mostly people are afraid to touch it. :)
I think what it will need is a concerted effort to hack up all of the gtk-using packages to be updated (in the manner we did to move to the 10.4 tree) and get everything moved at once.
so it seems nothing will happen in the near future :-)
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 Jul 2006, at 18:06 , Ben Fowler wrote:
On 01/07/06, jiho <jo.irisson@...400...> wrote:
On 01 Jul 2006, at 14:38 , jiho wrote:
[snip] I sent an email to the maintainers of GTK packages in Fink to have an idea of their schedule. [snip]
so it seems nothing will happen in the near future :-)
[snip] 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.
I asked Benjamain Reed if it was possible to provide both gtk2.4 and gtk2.8 (or 2.10) in fink so that other packages do not necessarily need to be updated.
Begin forwarded message:
From: "Benjamin Reed" <rangerrick@...400...> On 7/1/06, jiho <jo.irisson@...400...> wrote:
Thank you very much for the answer. Wouldn't it be possible to have both gtk 2.8 (for some "cutting edge" apps) and gtk 2.4 for compatibility reasons, so that every package does not have to move to 2.8 at once?
it would be hard to make them coexist without getting in the way of other packages... It would mean making an entire second tree of everything gnome-based, ultimately. Better to upgrade what we've got, it will just take a little planning.
so it seems that even if one of us provides packages for gtk, there will be an enormous additional work from the fink team to get all other gtk-depending packages working. In addition, given that we do not even provide an up-to-date fink package for Inkscape itself, I am afraid providing packages for GTK will be difficult ;-)
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.
I don't think that adding all gtk in svn will be acceptable. The only possibility IMHO, if 2.8 is really needed and that Fink does not provide it, is to get the few people compiling Inkscape for OS X to install it separately (we should be 3 or 4 max) and ship inkscape only as dmg packages (i.e. there won't be a new fink package until fink updates GTK but there is no up to date package currently anyway). Considering present situation, it is not much of a problem since there are very few people compiling inkscape on OS X. It's not a very promising solution for the long run though.
What about Universal Binaries?
I know that obtaining an universal binary of an XCode project is a matter of clicking a button but do not know much more. I guess it might be more complicated than that for non OS X'ish programs.
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:
On 01 Jul 2006, at 18:06 , Ben Fowler wrote:
On 01/07/06, jiho <jo.irisson@...400...> wrote:
On 01 Jul 2006, at 14:38 , jiho wrote:
[snip]
[ snip ] it would be hard to make them coexist without getting in the way of other packages... It would mean making an entire second tree of everything gnome-based, ultimately. Better to upgrade what we've got, it will just take a little planning.
so it seems that even if one of us provides packages for gtk, there will be an enormous additional work from the fink team to get all other gtk-depending packages working. In addition, given that we do not even provide an up-to-date fink package for Inkscape itself, ...
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 ...
I am afraid providing packages for GTK will be difficult ;-)
... It doesn't sound at all viable, more that just 'difficult'.
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.
I don't think that adding all gtk in svn will be acceptable.
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.
The only possibility IMHO, if 2.8 is really needed and that Fink does not provide it, is to get the few people compiling Inkscape for OS X to install it separately (we should be 3 or 4 max) and ship inkscape only as dmg packages (i.e. there won't be a new fink package until fink updates GTK but there is no up to date package currently anyway).
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!
What about Universal Binaries?
(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 01 Jul 2006, at 22:48 , Ben Fowler wrote:
On 01/07/06, jiho <jo.irisson@...400...> wrote:
On 01 Jul 2006, at 18:06 , Ben Fowler wrote:
On 01/07/06, jiho <jo.irisson@...400...> wrote:
On 01 Jul 2006, at 14:38 , jiho wrote:
[snip]
[ snip ] it would be hard to make them coexist without getting in the way of other packages... It would mean making an entire second tree of everything gnome-based, ultimately. Better to upgrade what we've got, it will just take a little planning.
so it seems that even if one of us provides packages for gtk, there will be an enormous additional work from the fink team to get all other gtk-depending packages working. In addition, given that we do not even provide an up-to-date fink package for Inkscape itself, ...
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 ...
you must also provide the .info and .patch files + accept to provide some support I guess. Be that as it may, I withdraw everything I wrote: Michael actually updated the package in Fink! which is great because people might discover Inkscape this way.
[snip]
I don't think that adding all gtk in svn will be acceptable.
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.
The only possibility IMHO, if 2.8 is really needed and that Fink does not provide it, is to get the few people compiling Inkscape for OS X to install it separately (we should be 3 or 4 max) and ship inkscape only as dmg packages (i.e. there won't be a new fink package until fink updates GTK but there is no up to date package currently anyway).
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.
- 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 .
- 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.
- 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.
- 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 agree with all that. I think I just like the idea of having a nice package management system with everything in it as you get in all linux distros. It is one of the main advantages of linux for me and I hoped that fink could provide this for OSX. But you are right, if Fink is too slow compared to Inkscape development, OS X compiling will require to provide the libraries independently from Fink. I'll happily try to compile everything needed.
What about Universal Binaries?
(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.
Fink seems to separate PPC and x86 architectures indeed. I remarked that the second release dmg for Inkscape (0.44-1) is marked as universal while the first one was not (if I remember well). Michael can you explain how this is done? Is it all automatized in osxapp.sh? Thanks in advance for your lights.
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 Sun, 2 Jul 2006, jiho wrote:
(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.
Fink seems to separate PPC and x86 architectures indeed. I remarked that the second release dmg for Inkscape (0.44-1) is marked as universal while the first one was not (if I remember well). Michael can you explain how this is done? Is it all automatized in osxapp.sh? Thanks in advance for your lights.
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
On Jul 2, 2006, at 5:56 PM, Michael Wybrow wrote:
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.
I've just about got a somewhat messy version of a long-term solution up and running. I got my first clean build of gtkmm tonight scripted out and I'm testing the entire script at the moment. The package versions I'm building are:
libiconv-1.9.2 gettext-0.10.40 pkgconfig-0.17.2 glib-2.10.3* jpeg-6b# tiff-3.8.2# libpng-1.2.10# gc6.7* libxml2-2.6.24# libxslt-1.1.16# atk-1.11.4 cairo-1.1.10 pango-1.13.2 gtk+-2.8.20* libsigc++-2.0.17 glibmm-2.10.4 gtkmm-2.6.4
*-denotes a package that requires separate builds and lipo for each target cpu #-denotes a package with libraries already included in the MacOSX.sdk, but for which headers aren't provided
I've discovered that a lot of fink dependencies can be sidestepped, and it seems like the major reasons that fink isn't going universal are a) that libtool becomes a 5-gallon can of worms and b) it makes their dependency tracking nightmare worse.
I haven't tried to build Inkscape yet, but I'd appreciate some comments on the library versions I've selected (arbitrarily).
I'll also mention that I owe a lot to Bryan Berg's work on his mono.universal distribution, which demonstrates a number of techniques for fighting with automake and Apple's linker. If anyone else is interested in taking a look, I'll post the latest versions.
--David H
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 7/1/06, jiho <jo.irisson@...400...> wrote:
[...snip...] gtk+2 and gtkmm2.4 are at version 2.6.4 in Fink unstable. I was wondering about the schedule of the integration of version 2.8 in Fink (given that 2.10 should be out shortly). [...snip...]
To be honest, I think mostly people are afraid to touch it. :)
I think what it will need is a concerted effort to hack up all of the gtk-using packages to be updated (in the manner we did to move to the 10.4 tree) and get everything moved at once.
so it seems i nothing will happen in the near future :-)
Are the OSX ports of gtk+/gtkmm and companions developed enough that we can drop fink altogether? Or even close? This is would eliminate the dependency on the fink development cycle for the Mac ( but shifts it to the porters of gtk+/gtkmm). We already build libs for windows, and i'm sure its possible on the Macs but is it worth the extra effort.
Joshua L. Blocher verbalshadow
On 01 Jul 2006, at 19:12 , Joshua Blocher wrote:
Are the OSX ports of gtk+/gtkmm and companions developed enough that we can drop fink altogether? Or even close?
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...)
This is would eliminate the dependency on the fink development cycle for the Mac ( but shifts it to the porters of gtk+/gtkmm).
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.
We already build libs for windows, and i'm sure its possible on the Macs but is it worth the extra effort.
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, 2006-07-01 at 11:23 -0500, Bob Jamison wrote:
but the memory footprint would be the same as when you launch dynamically-bound Inkscape, and the C++ .so's need to be loaded.
That isn't strictly true -- in the dynamically-bound case, you will be sharing text pages with any other applications that happen to have the same libraries loaded.
In the statically-bound case, you pay the full price for every process which is statically linked with the libraries.
-mental
On Sat, 1 Jul 2006, jiho wrote:
On 01 Jul 2006, at 14:38 , jiho wrote:
On 01 Jul 2006, at 14:15 , Ben Fowler wrote:
Mac OS X - fink has 2.4.9 in stable; anything more recent that 2.6.10 will cause disruption, I fear.
Here is the answer I received from Fink GTK packages maintainers.
Begin forwarded message:
From: "Benjamin Reed" <rangerrick@...400...>
To be honest, I think mostly people are afraid to touch it. :)
I think what it will need is a concerted effort to hack up all of the gtk-using packages to be updated (in the manner we did to move to the 10.4 tree) and get everything moved at once.
so it seems i nothing will happen in the near future :-)
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
participants (8)
-
Ben Fowler -
Bob Jamison -
Bryce Harrington -
David Himelright -
jiho -
Joshua Blocher -
MenTaLguY -
Michael Wybrow