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

[Andrea Canciani]

On Mon, Feb 9, 2015 at 7:13 PM, Ryan Schmidt <cairo-2015 at ryandesign.com>
wrote:

>
> On Feb 9, 2015, at 8:26 AM, Andrea Canciani wrote:
>
> > 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/ ).
>
> "Support" is different from "works" or "doesn't work". We "support" the
> last few versions of OS X, meaning if something in MacPorts doesn't work on
> those systems, we intend to fix it. MacPorts itself "works" on 10.4 and
> later; there is no reason to artificially break MacPorts on older systems
> that it still works fine on. MacPorts "doesn't work" on 10.3 and earlier
> (it doesn't compile, and hasn't for many years). Whether any individual
> port works on any particular system is another matter entirely. Many ports
> still work on 10.4, just as many others do not. Over time, as software is
> updated and developers stop testing on older systems, the number of ports
> failing to compile or run on older systems inevitably increases.
>

> > Would it be possible to keep cairo 1.14 on 10.4 and to only upgrade on
> other MacPorts targets?
>
> Possibly. MacPorts was never designed to have a port whose version number
> can change based on OS version or other criteria, but it has been done once
> or twice before. As long as newer versions of cairo don't fix bugs or
> introduce new features that other software relies on, this could work. It
> would add a lot of code to the cairo Portfile -- more code, I'm guessing,
> than if the problem were just fixed correctly.
>

The problem we are facing is that Apple's libraries are incompatible
between 10.4 and recent versions of the operating system: the 10.4 version
does not provide CoreText, while in 10.10 they deprecated the old font API
(and in iOS 8 they apparently removed it).
It is not completely clear what to have this problem "fixed correctly".
We can introduce a compatibility layer in cairo, so that it can attach to
whatever underlying API is available (my suggestion above). This would
obviously increase the complexity of cairo and it would make it harder to
test.
Alternatively we can fix the problem for 10.10 in the most straightforward
way. This prevents cairo from working on some old systems (10.4), but I
assume that it might be an acceptable compromise (if you want to run the
very latest version of libraries/programs, you might also have to update
the operating system).


> > What is the usual approach in MacPorts for software that depends on
> modern systems (example: latest LLVM versions)?
>
> The usual approach for ports that cannot be installed on a user's system
> is for them to print a message explaining why. In the case of llvm, we
> maintain multiple ports, one for each major version of llvm, so that users
> on older systems can still install the latest version that works for them.
>

This approach looks very convenient! Would forking cairo-1.14 and
cairo-latest involve complex changes to the Portfile?

> 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).
>
> Well Firefox already requires 10.6 or later. 10.4 support was dropped
> years ago, leading to the creation of TenFourFox to fill the gap. I don't
> see a reason to arbitrarily drop support for older systems, but if you
> choose to require 10.6 or later, that means you'll be dropping support for
> all Macs having PowerPC processors; 10.6 and later require an Intel
> processor.
>

Sorry, I did not mean to express the intention to artificially break cairo
on 10.5.
I would not actively prevent cairo from working on old versions, but I
think it might now be reasonable to accept changes that improve cairo or
fix issues on recent versions even if they break the old ones.
In particular, the commit being discussed above breaks 10.4, but it seems
to be required in order to let cairo-quartz work on MacOSX 10.10 and iOS 8.

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