-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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.
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
opus: revert to autotools #23727
opus: revert to autotools #23727
Conversation
Latest update in 6c3db5d has switched build system to Meson, which is broken on several non-SIMD platforms. Turns out, Meson support is not yet stable enough in the upstream, so we revert to autotools and drop meson-related patch. Signed-off-by: krant <[email protected]>
Is there any reference for it? Did you report it to upstream? If not, please do that. |
|
In any case, your report is different hence report it to upstream to get this fixed. |
I have no idea what are you talking about. This PR is fixing build errors in OpenWrt project. If you want to talk about something else - I'm not interested. |
Should I close this PR? I am thinking about it, so.
Sounds like you chose a random issue, and found something, that suits your case, well it isn't as your issue is:
but the issue you linked is about AVX2. Once again, how relevant is it? It is not, so do you really think that we will narrow things upstream on your behalf? No way that won't happen. |
@1715173329 @stangri @mhei @feckert @neheb @commodo @pprindeville @Ansuel |
There are some best principles which you should follow in the first place. I am glad that we do have this conversation. Let's go back to the history:
If something happened with the commit B, we could easily revert it.
I was wondering if I should reply here something, but how time-consuming it was to write your comment instead of using your efforts more effectively and creating an opus developers issue about the issue that you experienced instead of reverting it? I will leave you here some pages, which you should read and follow: |
BTW the package is clearly broken on buildbots as well, so IMO @1715173329 (who have reviewed and merged the initial contribution), have now one of the following options:
and handle the package update and switch to meson again properly, its not end of the world, right? We've Git reverts for exactly such reasons. Moreover we should consider adding such currently failing platform to the CI testing matrix, so we catch the build breakage here and not later. |
So, things got heated here. To me, it looks like both parties read the message (from the other party) with a different tone that was probably intended. Keeping things at a technical level, I would also (just) vote on fixing the build error. I guess that's all I can add. |
#23661 (comment) I don't know what happened to BKPepe, he seems to become very "irritable" since last year. Meson is not enforced, is not something that we have to use. We (try to) migrate to meson for faster compilation, just like CMake, it's simpler , it's the "modern" buildsystem. |
Yes, meson allows problem free and fast compilation. I’d like to see meson get fixed personally, but no problem reverting to auto tools for now. As upstream has said, auto tools is the primary build system. The others are not supported in the same way. |
I don't see @BKPepe in that discussion/thread. But it now looks to me like an age-old "young-people clashing with old-people" issue. FWIW: I haven't seen any good way to resolve this sort of conflict. Whether @BKPepe has become more irritable or not: ¯\_(ツ)_/¯ During my early contributor days, I've always tried to make things easier for the maintainer(s). Going back to the technical part, let's fix this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
It's really a shame that there was an enormous discussion about who is wrong, who wants to cooperate with upstream. However, from my observation, I can see that some developers would appreciate it if the downstream cooperated with the upstream and vice versa. My intention to close this issue was to force the user to report a bug with upstream, which I did on his behalf, because no one else could do that and I was the bad guy. I see that @krant created a few PRs recently here, but he did not look at the issue further even I sent him reminder. (xiph/opus#327) It was not my intention to be rude and I hope I was not, but it is what it is, though. The issue could be fixed in the upstream. One wise guy told me that I should no longer help users, if they dont want to help and let the show that things could be and should be done entirely different. We could merge things like others wants, if thats what majority wants. I'm glad that people who aren't really that active in this repository joined this discussion. I will focus on my things, now! :) Based on statistics, yeah. New contributors could have entirely different options than current ones, that happens over the time and I really doubt that if anyone could be still have enormous energy and review atleast 2-3 PRs day here without getting into any conflicts as I have been told. |
make some kids :) i try to be more ¯\_(ツ)_/¯
i've had my share of conflicts too; |
Make love, not war 🕊️
This pull request contains a fix for a build failure, authored by the same person who introduced the issue. In my opinion, there were only two options: either fix it yourself or accept the proposed fix. To my knowledge, there aren't any specific rules or guidelines that require contributors to report issues upstream before accepting fixes for build problems, moreover when the contributor clearly demonstrated, that he actually cares and made upstream aware via a comment. However, there is an unofficial/unwritten "upstream first" philosophy that many of us try to adhere to when possible. This typically involves resolving the issue upstream and then backporting the fix downstream. If there's any uncertainty, one can always refer to the OpenWrt Project Rules, specifically rule 12: "Be nice to each other" which can be applied as a fallback. |
Maintainer: @thess @antonlacon
Compile tested: bcm53xx
Description:
Latest update in 6c3db5d has switched build system to Meson, which is broken on several non-SIMD platforms. Turns out, Meson support is not yet stable enough in the upstream, so we revert to autotools and drop meson-related patch.
Example of build error this PR fixes: