Sigh, almost as bad as QT 5 minors being majors without ever bumping the 5 because "qt5" is a marketing brand they don't want to replace from the commercial standpoint.
On Tue, Aug 4, 2020 at 9:15 AM Ian McInerney <ian.s.mciner...@ieee.org> wrote: > > > On Tue, Aug 4, 2020 at 1:44 PM Mark Roszko <mark.ros...@gmail.com> wrote: > >> Been working on Phoenix, I basically have something working to build, >> though it'll be awhile before I have anything to share. >> >> >> However, here's the fun part: >> wxPhoenix 4.1.0 only works with wxWidgets 3.1.4 and above >> wxPhoenix 4.0.7 only works with wxWidgets 3.0.x series >> >> There's a fun gap with 3.1.0-3.1.3 :D Basically even with their fancy >> pancy dynamic generation system for most of their code. They hardcoded >> things specific references with no version checking fallback. Even the >> 4.0.x series may have some compatibility issues with wx 3.0.x depending on >> mix. >> >> wx is to blame too because wxWidgets 3.1.4 has API changes that >> really should have made it 3.2. Hell, 3.1.4 appears to have enabled a >> newer C++ standard and the build is broken for MSVC until you patch it with >> master because Microsoft under some newer standard flags clamped down on >> STL export violations. >> >> > wxWidgets follows a "development series" version system - only the even > numbers are stable releases (e.g. 2.9, 3.0, 3.2, etc.), so anything in 3.1 > is going to have API/ABI changes happening as they change the API and > stabilize it before the next stable release (the full list of changes from > 3.0 to the current 3.1/future 3.2 is here > https://github.com/wxWidgets/wxWidgets/blob/master/docs/changes.txt). > This on its own isn't a problem, the real problem is that 3.1 has been in > development for a long time and hasn't been released as a stable release > yet. > > >> I have a PR update to vcpkg to go to 3.1.4 and patch it for MSVC. >> https://github.com/microsoft/vcpkg/pull/12733 >> >> >> >> On Tue, Aug 4, 2020 at 7:41 AM Wayne Stambaugh <stambau...@gmail.com> >> wrote: >> >>> On 8/3/20 9:19 PM, Seth Hillbrand wrote: >>> > >>> > >>> > On Mon, Aug 3, 2020, 10:48 AM Wayne Stambaugh <stambau...@gmail.com >>> > <mailto:stambau...@gmail.com>> wrote: >>> > >>> > I'm not ready to drop 32 bit builds for V6. I still think there >>> are >>> > enough 32-bit users to warrant supporting it for one more >>> release. It's >>> > something we can discuss for V7. >>> > >>> > >>> > If we keep 32 bit builds on mingw2, does that mean that we freeze all >>> > packages at their current versions? It might be problematic to keep >>> > different package versions for different architectures. >>> >>> I'm assuming you mean dependency packages so yes we would continue to >>> build 32 bit windows versions using the current package versions. If >>> someone figures out how to get wxPhoenix to build, then we could bump to >>> wxWidgets 3.1.x and Python 3.x. >>> >>> > >>> > Obviously, if we successfully move to MSVC, this question is moot. >>> > >>> > -Seth >>> > >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> -- >> Mark >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > -- Mark
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
