Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[WIP] wxpython 4.2.0a1 and wxWidgets 3.2.0 related changes #12007

Closed
wants to merge 3 commits into from
Closed

[WIP] wxpython 4.2.0a1 and wxWidgets 3.2.0 related changes #12007

wants to merge 3 commits into from

Conversation

stahta01
Copy link
Contributor

@stahta01 stahta01 commented Jul 6, 2022 •
edited

Major changes include:

  1. Renamed mingw-w64-wxWidgets to mingw-w64-wxWidgets3.0
    Removed wx-config and other items from mingw-w64-wxWidgets3.0 package
  2. Renamed mingw-w64-wxWidgets3.1 to mingw-w64-wxWidgets
    a. Add split package wxconfig
    b. Add split package msw_cb_headers
    c. Upgrade wxMSW to 3.2.0
  3. Updated wxPython to 4.2.0a1 and wxWidgets 3.2.0

Note: The PR #12011 needs applied before this one.

@stahta01 stahta01 changed the title wxpython 4.2.0a1 and wxWidgets 3.2.0 related changes [WIP] wxpython 4.2.0a1 and wxWidgets 3.2.0 related changes Jul 6, 2022
@ZachBacon
Copy link
Contributor

I don't agree with swapping out wxwidgets package with 3.1, currently 3.1 series is considered still as a development package and even if it's considered stable enough, shouldn't supplant the current stable until an actual new stable is released.

@stahta01
Copy link
Contributor Author

stahta01 commented Jul 6, 2022 •
edited

I don't agree with swapping out wxwidgets package with 3.1, currently 3.1 series is considered still as a development package and even if it's considered stable enough, shouldn't supplant the current stable until an actual new stable is released.

True; but you do understand what draft and work in progress mean, right?
And, doing an PR lets others test the package with a slightly greater ease.

Tim S.

@stahta01
Copy link
Contributor Author

stahta01 commented Jul 6, 2022 •
edited

Any opinion on when to change this PR from draft?
The day of the wxWidgets release and a week after the release both sounds good to me.

Edit: The RC2 does not have an full download tar; for the ones who wonder why I did RC1.
Edit2: wxWidgets 3.2.0 was just released.

Tim S.

@stahta01 stahta01 mentioned this pull request Jul 6, 2022
Merged
@stahta01 stahta01 force-pushed the wxpython4.2.0a branch 2 times, most recently from d3f07f9 to 0172644 Compare July 7, 2022 04:53
@mmuetzel
Copy link
Collaborator

mmuetzel commented Jul 7, 2022

I don't have a complete picture of this transition. But I slightly agree with @ZachBacon.
IIUC, wxWidgets 3.2 breaks API compatibility to wxWidgets 3.0. If that is true (and please correct me if I'm wrong), we should probably give dependent packages some time to adapt to the new API before defaulting to it. I don't know what would be a good time frame for that. Maybe a couple of months after the release of wxWidgets 3.2? Half a year? Longer?

@ZachBacon
Copy link
Contributor

I don't have a complete picture of this transition. But I slightly agree with @ZachBacon.
IIUC, wxWidgets 3.2 breaks API compatibility to wxWidgets 3.0. If that is true (and please correct me if I'm wrong), we should probably give dependent packages some time to adapt to the new API before defaulting to it. I don't know what would be a good time frame for that. Maybe a couple of months after the release of wxWidgets 3.2? Half a year? Longer?

From the release notes, it looks like it's still Abi compatible with 3.0

"We recommend using this version for any new wxWidgets applications. Existing applications using wxWidgets 3.0 or 3.1 shouldn't require any special effort to upgrade to this version too, so please try upgrading them to it."

https://github.com/wxWidgets/wxWidgets/releases/tag/v3.2.0

@mmuetzel
Copy link
Collaborator

mmuetzel commented Jul 7, 2022 •
edited

Thanks for the hint. 👍
It's still not entirely clear to me though. IIUC, they only promise ABI compatibility for the 3.2.x release series. (3.0.x and 3.2.x might still be ABI incompatible.)
The following sentence might mean that 3.0.x and 3.2.x are still API compatible. So, rebuilding all dependencies might be enough. (And they wouldn't need to change their code.) Is that correct?
That might make the transition a bit easier...

@stahta01
Copy link
Contributor Author

stahta01 commented Jul 7, 2022 •
edited

I don't have a complete picture of this transition. But I slightly agree with @ZachBacon. IIUC, wxWidgets 3.2 breaks API compatibility to wxWidgets 3.0. If that is true (and please correct me if I'm wrong), we should probably give dependent packages some time to adapt to the new API before defaulting to it. I don't know what would be a good time frame for that. Maybe a couple of months after the release of wxWidgets 3.2? Half a year? Longer?

The packages in this repo should all stay at 3.0; that is what my other PR did.
And, both wxWidgets3.0 and wxWidgets (3.2) can be installed at the same time; I have been thinking about this change for over two years. The other PR was already applied see #12011

Edit: Or are you talking about third party packages?
If third party packages, I do have a way to make them easier to rebuild; it requires more changes to the newly named wxWidgets3.0 package.

Tim S.

@stahta01
Copy link
Contributor Author

stahta01 commented Jul 7, 2022 •
edited

List of changes to help third party conversion to wxWidgets versions 3.0 and 3.2.
Edit: By help I mean they will keep using wxWidgets version 3.0 shared DLLs when rebuilding the third party package.
Note: All packages using wxWidgets3.1 will need work. And, packages using static wxWidgets 3.0 will need work.

wxWidgets3.0 package changes.
Make into split package

  1. wxmsw3.0
  2. wxconfig; that by default finds wxmsw3.0 dll.
  3. wxWidgets meta package that results in wxmsw3.0 and wxconfig being installed.
    Review of package wxmsw3.2 to confirm it has no issues with meta wxWidgets being installed.
    Note: the wxconfig from the two packages, 3.0 and 3.2. will conflict with each other.

I just got paid programming job; so, it could be a few weeks before I can do above.

Tim S.

@stahta01
Copy link
Contributor Author

stahta01 commented Jul 7, 2022 •
edited

https://wxwidgets.org/news/2022/07/wxwidgets-3.2.0-final-release/

I think this PR should be split into two, one for wxWidgets upgrade and the other for wxPython

I do not really think that makes sense; but, I also see no downside; so, I will do another PR to do the wxWidgets 3.2 and 3.0 changes when I get them done.

Tim S.

@stahta01
Copy link
Contributor Author

stahta01 commented Jul 8, 2022 •
edited

I am working on another PR for the wxWidgets 3.0 and 3.2 packages; it is being written to allow third party packages to build using the new packages with only minor changes for most of them.

Tim S.

@stahta01 stahta01 force-pushed the wxpython4.2.0a branch 2 times, most recently from fbc27ba to 285648b Compare July 9, 2022 00:09
@stahta01
wxWidgets3.0: Rename from wxWidgets and
6fce3f9 
convert to split packages wxmsw, wxconfig, bakefile, locale, and wxrc.
Also, add wxWidgets meta package that depends on wxmsw, wxconfig,
locale, and wxrc.
@stahta01
wxWidgets: Rename from wxWidgets3.1 and
1f532a4 
convert to split packages wxmsw, wxconfig, bakefile, locale, and wxrc.
Also, add wxWidgets3.2 meta package that depends on wxmsw, wxconfig,
locale, and wxrc. The split package msw_cb_headers is added to aid in
building the IDE Code::Blocks. Also, prevent CLANG32 from using
"-mthreads".
@stahta01
wxpython: update to 4.2.0a1 and wxWidgets 3.2.0
e92fec9
@stahta01
Copy link
Contributor Author

stahta01 commented Jul 9, 2022

Closing this till after I get my new wxWidgets 3.2.0 split package to build.

@stahta01 stahta01 closed this Jul 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@stahta01 @ZachBacon @mmuetzel