Open barracuda156 opened 3 weeks ago
We rely on all sorts of features and fixes from more recent wxWidgets.. 3.0 was released over 10 years ago, it would not make sense to try and support old versions that far back.
We rely on all sorts of features and fixes from more recent wxWidgets.. 3.0 was released over 10 years ago, it would not make sense to try and support old versions that far back.
@aardappel Will it be possible with limited functionality, i.e. instead of trying to actively support it, just conditionally disable some features?
If not, maybe you could refer me to the version which was last to support wxGTK 3.0? Or time frame at least, when support was dropped.
MacPorts has a rather old treesheets
from 2021, and that one builds with no patches with wxGTK 3.0. I would like to update it, but I need to know which one to pick.
Not too bad, actually. Save for a bug with redefined ssize_t
which seems unfixed for years (but it is in a lobster
library), 2023 version builds fine with wxGTK 3.0.
So perhaps it was not dropped long back, just too many tags are there to find out manually.
UPD. This might be the first breaking commit: https://github.com/aardappel/treesheets/commit/1e9f110bf876eed7bd9f17e8c3badf2c9c0be589
@aardappel If you could recommend which version to pick, it would be helpful. Very likely that some number of initial breaking changes could be trivially reverted, and the app gonna work. But I cannot try every tag between April 8, 2023 (last version which builds) and the current master (which fails). Is there some sensible pick, which you think may still work with minimal changes to the code (I can handle that on my side, provided no rewriting is needed, and we can keep it locally in MacPorts).
Even if it builds, we've run into many issues which were fixed on their side over the years (for which we may or may not have workarounds that may have been removed), meaning even it builds, random things may misbehave or crash.
We are also a very small project, and it is not worth our effort to try and have backwards compatibility.
Much better to build with newer libraries. You generally don't want to build against libraries in a package manager, instead use the latest from github.
@aardappel Well, it is not that I do not like wxWidgets
3.2 for no reason :) It is just broken on older versions of macOS, native perhaps hopelessly, while the current wxGTK
is just broken on any macOS: https://github.com/wxWidgets/wxWidgets/issues/24460
Of course a better way would be to fix wxGTK
, but I have only that much time.
We are also a very small project, and it is not worth our effort to try and have backwards compatibility.
I perfectly understand. I only meant that if adding some macros once gonna fix it, it is worth doing. Ongoing rebasing is unmaintainable, of course, and neither I ask for that nor gonna do it myself for MacPorts.
I tried reverting a few breaking commits, but there are a lot, apparently, so for now I did this: https://github.com/macports/macports-ports/blob/e70331f4f156e4667bfcbdd513db9d11bcc84d7e/editors/treesheets/Portfile It allows a decently recent version to run on 10.6 on a PowerPC :)
@aardappel Would it be possible to fix it for wxGTK 3.0? Currently the build reaches 94% and the breaks down:
Dropping the header does not help, expectedly: