[cairo] patches for configure errors under MinGW, OS X deprecation warnings
cairo-2015 at ryandesign.com
Tue Feb 10 01:11:49 PST 2015
On Feb 9, 2015, at 1:23 PM, Andrea Canciani wrote:
> On Mon, Feb 9, 2015 at 7:13 PM, Ryan Schmidt 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).
As I said, anyone running 10.4 today is probably doing so out of necessity of the old hardware they have. "Update the operating system" in that case will mean spending money on a new computer, and throwing out old still-working hardware. I am a proponent of continuing to allow old hardware to be useful.
The fix I would suggest is to use autoconf to determine if CTFontRef is available. If so, use it; if not, use the old code. There's only a few lines of code that were touched in the commit so it doesn't seem like it would be very difficult to introduce a few #ifdefs.
>> > 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?
This is not the norm in MacPorts, and it is not straightforward or convenient. Since we're only talking about a few lines of code at this point, if this issue is not fixed in cairo, I will almost certainly prefer to maintain the small patch to go back to using the pre-CoreText function on 10.4 than package multiple versions of cairo in MacPorts.
>> > 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.
Sure, if it is necessary to break old systems to fix new ones, that's best. In this case it seems like it should be possible to write the code in such a way that both can work, however.
More information about the cairo