[cairo] patches for configure errors under MinGW, OS X deprecation warnings

Andrea Canciani ranma42 at gmail.com
Mon Feb 9 06:26:53 PST 2015


On Mon, Feb 9, 2015 at 4:28 AM, Ryan Schmidt <cairo-2015 at ryandesign.com>
wrote:

>
> On Feb 8, 2015, at 7:31 PM, Bryce Harrington wrote:
>
> > On Sun, Feb 08, 2015 at 01:10:16PM +0100, Andrea Canciani wrote:
> >> On Sun, Feb 8, 2015 at 11:17 AM, Ryan Schmidt wrote:
> >>> Would it be possible to keep the previous code for OS X 10.4 and use
> the
> >>> new code on OS X 10.5 and newer?
> >>
> >> It is possible to do that, but testing on 10.4 is becoming pretty hard
> (I
> >> have no such environment and I'm afraid that Mozilla is not testing
> anymore
> >> on such an old OS). In the bugreport the agreement seemed to be that
> 10.4
> >> is too old to be supported. Its removal would also allow for a
> significant
> >> cleanup, as 10.4 is missing blend operators.
> >>
> >> I am unsure what the best course is... Chris, Bryce, what are your
> opinions
> >> on this?
> >
> > On the Linux distro side, LTS releases typically are supported no more
> > than 5 years, so Ubuntu's 8.04 Hardy Heron released in 2008 was no
> > longer supported as of 2013.  If someone asked about a Cairo problem
> > that was specific to Hardy and not an issue as of Lucid (10.04), I'm
> > fairly sure we'd close the bug with a recommendation to upgrade.
> >
> > Wikipedia shows OS X 10.4 released in 2003 with final point release in
> > 2007.  OS X 10.5 was released in 2007, with its last release in 2009.
> > I suppose OS X is a bit different than a Linux distro in that users
> > actually have to pay money for the upgrades, but that's sort of the
> > deal with the devil they made picking proprietary software.
> >
> > In Inkscape we require 10.5 or newer, and I think we've required that
> > for a while.  On the Linux side we support LTS's from 2012 and newer;
> > maybe a bit older for Fedora, I forget.
> >
> > I don't know if we have an established policy in Cairo, but setting a
> > expectation of an OS from 2008 or newer seems adequately conservative
> > for an established system library.  Seven years is longer than most
> > LTS's and probably beyond the typical lifespan of most consumer
> > hardware.
> >
> > So, my opinion is yes, I think we can bid 10.4 adieu.
>
> Understand that it's not just a matter of a user choosing not to upgrade
> the OS. There are many Macs which cannot be upgraded past 10.4 (as there
> are for every other version of Mac OS and OS X, of course). These are
> certainly old machines by now, but we do still have a handful of MacPorts
> users using 10.4. I would not be surprised if those users also have newer
> Macs running newer versions of OS X, but it is valuable to be able to still
> use older machines for something, and MacPorts helps users do that.
>
> I am the maintainer of cairo in MacPorts, where, with the recent cairo
> 1.14.0 update, I finally made the long-desired change to default cairo to
> enabling quartz, in addition to X11. Now, if quartz font support won't work
> on 10.4 anymore, I have to modify the port again, to either disable all of
> quartz on 10.4, or to just disable quartz font support on 10.4. If quartz
> font support is not used by anyone, that's fine, but if it is, then there
> will be build failures in those apps. I could also just maintain forever
> (or until MacPorts itself no longer works on 10.4) a patch to cairo to make
> quartz font compatible with 10.4 again by reverting this commit, but I
> would prefer not to have to maintain patches.
>

What is the policy for supporting old MacOS X versions in MacPorts?
The homepage seems to state that the main targets are the latest 3
versions, but it looks like over time the support for older versions was
preserved (at least based on the news here: https://trac.macports.org/news/
).
Would it be possible to keep cairo 1.14 on 10.4 and to only upgrade on
other MacPorts targets?
What is the usual approach in MacPorts for software that depends on modern
systems (example: latest LLVM versions)?

I can write a patch that implements the dynamic discovery of the available
API, which should restore support for 10.4, but I expect cairo to
eventually drop support for 10.4 (currently Cairo has no explicit support
timelines, but I think that keeping in sync with Firefox requirements would
make sense).

Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20150209/f1df4aec/attachment-0001.html>


More information about the cairo mailing list