It doesn’t appear to be possible to maintain compatibility with previous Haiku releases this close to the release of Emacs 30, during which we are very leery of potentially destabilizing changes, which is to say that additional configure tests are out of the question.
What is “cbfbbf6d”? Can you give a link to specific repo commit?
We usually deal with revisions, this one is hrev58605
https://cgit.haiku-os.org/haiku/commit/?id=cbfbbf6d4d0e9c28332e8c1f53bf7134896ac7d3
Anyway, we do indeed break source compat sometimes in the nightly branch. I don’t quite understand how this breaks compatibility with beta5? this change was not (and will not be) backported to beta5
Note that BObjectList change compatibility break can be fixed by adding mangled symbol aliases. Me or Waddlesplash can upload patch if needed.
We’re also attempting to target Nightly. Since you evidently don’t wish to break source compatibility between beta releases, I simply assumed that you’d appreciate the heads up.
Ah okay.
As far as I know we don’t keep api compatibility between betas, only abi for userspace applications.
anyhow, @waddlesplash authored that change, if he wants to comment.
We do break source compatibility between releases on occasion when it makes sense to; and in this case it did make sense to, as the commit message explains. But I see you’ve already adjusted Emacs to match here. Sorry for the break; I guess we could have announced it a bit better; I guess I would’ve figured most third-party applications would’ve been more likely to use the STL instead.
But I see you’ve already adjusted Emacs to match here
Yes, but we aren’t comfortable with backporting this patch to the release that is soon to become Emacs 30.1 when the release is so close at hand.
Haiku users will uses HaikuDepot to install Emacs, so the patch can live at haikuports till you’re ready. Really few will download sources to build things by themselves if it is already packaged. I’m not a dev but IMHO it doesn’t make sense to integrate such patches to your sources until next Haiku beta.
It does not need to. aslong as we break the api and not the abi the old version will run on nightlies aswell.
As we have no seperate haikuports branch for the nightlies we also have to pick in such situations, and the pick compatibility with the beta oder the nightly
It’s a problem for other third party apps, too.
If I understand correctly, any app which uses BObjectList, if compiled on beta5, won’t work in nightlies and vice versa.
Would be nice, thank you
Can you give an example of affected software?
Other than Emacs bere? Genio and Dockbert, for example.
This is not true. BObjectList is a template class, so changes to it only affect ABI if there are public methods that have it as a parameter. There aren’t many of these; and so far all the problems have been either with source compatibility or with applications using private API.
For Dockbert and others, we could potentially add ABI compatibility methods to libtracker to fix it for the moment.
But is BObjectList private API? I thought it was public since it’s in the public headers directory.
Is there any advice or guideline on how to handle this breakage in applications who needs to be built on beta5 AND nightly ?
I think you are mixing two things here: running existing apps and compiling them.
For running, the “applications using private API” is not about BObjectList, but some other private API that uses it. For example, Dockbert fails resolving symbol BPrivate::BNavMenu::BNavMenu(char const*, unsigned long, BMessenger const &, BWindow*, BObjectList<BString> const *)
, which is a private Tracker thing. Genio ran without issues for me, but maybe I just didn’t trigger something. An example of a simpler app compiled in beta that uses BObjectList
internally and works in both beta and nightlies is QuickLaunch.
Now, for compilation you are absolutely right. As the API changed, compiling old code on newer nightlies won’t find the old definitions. You can see what they did in Emacs, with autotools detection. StreamRadio takes a different approach, using B_HAIKU_VERSION
. That one would fail to compile in nightlies before the API change, but hey, if you are compiling stuff on nightlies you are living on the edge, not on older versions.