Opened 17 months ago

Last modified 17 months ago

#67628 new request

Any reason we do not have wxWidgets-3.1 port?

Reported by: barracuda156 Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.8.1
Keywords: Cc: mojca (Mojca Miklavec), mascguy (Christopher Nielsen)
Port: wxWidgets

Description

Did we have it earlier? I need at least wxWidgets-3.1 for a new port, and wxWidgets-3.2 is broken for PPC (fixable, kind of, but not in Macports so far).

Change History (8)

comment:1 Changed 17 months ago by barracuda156

Type: defectrequest

comment:2 Changed 17 months ago by ryandesign (Ryan Carsten Schmidt)

Last edited 17 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:3 in reply to:  2 Changed 17 months ago by barracuda156

Replying to ryandesign:

Yes, there is a reason: 3.1.x was the development branch for 3.2.

https://docs.wxwidgets.org/3.2/overview_backwardcompat.html#overview_backwardcompat_versionnumbering

Hmm, I see. Thank you.

I was going to make a port for rawproc, and its upstream uses wxWidgets-3.1 (it allows later versions too, but not 3.0, at least as of now). I will go through release notes to see if there is any sense for having 3.1 for <10.7 or not in terms of compatibility with SDK.

Last edited 17 months ago by barracuda156 (previous) (diff)

comment:4 in reply to:  2 Changed 17 months ago by barracuda156

Replying to ryandesign:

Yes, there is a reason: 3.1.x was the development branch for 3.2.

Upstream still has a release for it though: https://github.com/wxWidgets/wxWidgets/releases/tag/v3.1.7

comment:5 Changed 17 months ago by ryandesign (Ryan Carsten Schmidt)

Yes: a development release, like all 3.1.x releases:

wxWidgets 3.1.7 is the latest release in the 3.1 development branch

We usually want ports for stable releases in MacPorts.

comment:6 in reply to:  5 Changed 17 months ago by barracuda156

Replying to ryandesign:

Yes: a development release, like all 3.1.x releases:

wxWidgets 3.1.7 is the latest release in the 3.1 development branch

We usually want ports for stable releases in MacPorts.

From release notes, it does not help much over 3.2 anyway, requiring 10.11+ (!).

comment:7 Changed 17 months ago by mojca (Mojca Miklavec)

According to https://github.com/macports/macports-ports/commit/15a8f434cad82f465ddb7977d4dcb26d686540fe the version 3.1.2 apparently requires at least 10.8 SDK.

I haven't been paying much attention lately, so I'm no longer sure whether 10.11+ is in fact exact or not, though I would be somewhat surprised if you would be able to build 3.1 on 10.5 either without non-trivial patching. It's often not that the framework really needs those new versions, but they want to add a cool new feature and it's extra work (with no significant number of users) to keep compatibility for ancient macOS versions. Very often it's just an unconditionally added function call from a a newer SDK.

I don't expect super significant differences between 3.1 and 3.2. A package that works with 3.1 should probably work with very little (or no) effort with 3.2 as well. But neither of the two will build out-of-the-box on 10.5.

(I would slightly prefer if we didn't have to introduce another "development package" for this, but in case we would need to ...)

comment:8 in reply to:  7 Changed 17 months ago by barracuda156

Replying to mojca:

According to https://github.com/macports/macports-ports/commit/15a8f434cad82f465ddb7977d4dcb26d686540fe the version 3.1.2 apparently requires at least 10.8 SDK.

I haven't been paying much attention lately, so I'm no longer sure whether 10.11+ is in fact exact or not, though I would be somewhat surprised if you would be able to build 3.1 on 10.5 either without non-trivial patching. It's often not that the framework really needs those new versions, but they want to add a cool new feature and it's extra work (with no significant number of users) to keep compatibility for ancient macOS versions. Very often it's just an unconditionally added function call from a a newer SDK.

I don't expect super significant differences between 3.1 and 3.2. A package that works with 3.1 should probably work with very little (or no) effort with 3.2 as well. But neither of the two will build out-of-the-box on 10.5.

Thank you, I will look into fixing 3.2 then.

(I would slightly prefer if we didn't have to introduce another "development package" for this, but in case we would need to ...)

Yes, sure.

Note: See TracTickets for help on using tickets.