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
asmcomp "compile-time constants" do not work on cross-compilers #7250
Comments
Comment author: @gasche The PR you link to discusses a patch ( ocaml-cross/opam-cross-windows#5 ), but this patch is specific to cross-compiler targeting Windows. What we would like to have upstream is a more general support of a host/target distinction, with those values specialized according to the target rather than the host. But those patches will come from people working on cross-compilation already. Do you know if anyone is working on this more general approach? Could your Windows work then be rebased on top of that? I'm tempted to "suspend" the PR as a way to mark that maintainers are unlikely to work on that in the short term, and that external contributions, in particular from people already working on cross-compilation, woud be warmly welcome. |
Comment author: @whitequark Yes. The patch is a hack. It is a hack and not a proper patch because I have no earthly clue as to how to do it decently. I am unaware of anyone else working in that direction or even being aware of the problem. |
Comment author: @whitequark @gasche Huh? Why did you mark this as "resolved"? This is absolutely not resolved in any way, what you did was just made sure that the issue will be promptly forgotten. |
Comment author: @gasche I believe that "suspended" is the right status for this PR, and this is accessible under the "resolved" parent status. The status name is indeed misleading (the issue is not resolved), but it has the intended consequence that maintainers will not come back to the issue on each new release, but rather wait for someone (maintainer or not) to make progress and reopen the case. In my mind "resolved > suspended" should be interpreted as "this issue is not going to move by itself, if you care about it you should probably work on it yourself". |
Comment author: @whitequark Well, that's a probably the second most hostile and unproductive way to regard an issue like this after closing it with a comment saying "we don't give a damn". In fact, you've just guaranteed that if I ever fix this myself, I won't bother upstreaming it. |
Comment author: @dbuenzli Gabriel, this way of proceeding makes little sense to the end-users of the OCaml system, unless, in that particular case, the dev team doesn't give a shit about cross-compilation which AFAIK is not the case given the recent improvements that were merged. The BT is already hard to search for issues so if we start marking as resolved, issues that are not we are not going anywhere. If this is a BT usability issue for release managers please find another way to resolve it (e.g. by tagging it with 'needs help' so that these bugs can be easily ignored by them). This feels like sweeping issues under the carpet. |
Comment author: @gasche whitequark, I'm not sure why you are reacting this strongly. I moved the issue back to "confirmed" land, with apologies for making unpleasing triaging choices. I guess you and Daniel are right that this resolution makes little sense. In fact I just found out that moving a "resolved > suspended" issue back into non-resolved land keeps the "suspended" bit, which is... interesting and could be of use in the future. I think the important bit here is the "cross-compilation" tag which I added, which guarantees that as soon as someone starts working more thoroughly on cross-compilation they will be able to find the issues that would need fixing. If you see a cross-compilation issue that lacks the tag, please add it or ping me to do so, it's helpful. (Indeed, the dev team is interested in improving cross-compilation in general.) |
Comment author: @damiendoligez
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
I think there was an effort to fix this systematically, but I don't know if this issue is fully fixed, and I couldn't quickly determine if it is. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Stop with the stale labels already. |
Agree with @whitequark. In Rizin project we also initially enabled the stalebot but after year of use it was considered an annoyance and harmful since not all old issues are irrelevant even after many years of existence. Closing all bugs will not happen anyway, thus the number of opened issues should not be gamified, in my opinion, and issues treated as a kind of knowledge base, sometimes actionable and useful, even with workaround information. Drew DeVault wrote a good article about it: https://drewdevault.com/2021/10/26/stalebot.html |
It is plainly disrespectful to anyone who spends their time investigating and filing bugs. Especially considering that this specific issue has a long history of maintainers being disrespectful! Anyway, I am going to harass people here about the stalebot until they fix it or ban me. |
I agree that the stale bot is bad and I would rather have it go away -- I agree with the post by Drew. There is obviously disagreement about this among compiler maintainers; some maintainers want to close PRs/issues that are going nowhere, and the stale bot helps with that. I am pretty sure that "harass[ing] people here" is not going to improve the situation in any way; please don't do that. The bug still exists today, and it is still the case that it is waiting for someone working on cross-compilation to be solved properly. To my knowledge the best documentation of cross-compilation today is in the Diskuv documentation by Jonah Beckford. It documents several limitations, including the one in the present issue report. I am closing this issue because it will make the stale bot go away, which is fine, and not prevent discussion in any way. If someone actually starts working on cross-compilation for OCaml, they should feel free to reopen. |
The "completed" here perfectly complements the attitude that brought the stalebot online. I'll make sure to close all of the other issues I've opened, since it's clear that no one cares about them and there is no point in doing anything else. |
Thank you, @gasche. |
Two comments:
|
I apologize for my earlier remarks (both the recent one and the one made many years before), I agree that I was out of line in both cases, and I'll make sure to approach the project in a different manner from now on. That being said, I must mention that I only do so because you are someone I have a lot of respect personally as a result of many interactions over the years (on here, on #ocaml IRC, on StackOverflow and probably elsewhere). |
Original bug ID: 7250
Reporter: @whitequark
Status: confirmed (set by @gasche on 2016-05-10T10:54:17Z)
Resolution: open
Priority: normal
Severity: minor
Target version: later
Category: platform support (windows, cross-compilation, etc)
Tags: cross-compilation
Monitored by: @hcarty @dbuenzli
Bug description
Please see ocaml-cross/opam-cross-windows#4.
The text was updated successfully, but these errors were encountered: