Re: cmake stuck on mips
Havard Eidnes <[email protected]> Wed, 16 Jul 2025 19:49:31 +0200 (CEST)
| Newsgroups | gmane.os.netbsd.ports.mips.devel |
|---|---|
| Message-ID | <[email protected]> |
>> I passed this under mrg@'s nose, and he commented that it's >> probably unlikely that gcc14 for mips in pkgsrc will work, we are >> carrying around our own patches for our in-tree compiler which >> have evidently not been passed on upstream. It would have been >> nice to not waste so much time... Is there a particular reason >> which makes our mips adaptations unsuitable or unacceptable by >> the gcc maintainers? > > Have they ever been offered in the first place? Possibly not. It requires a certain combination of "first-hand knowledge of what those diffs do", "ability to possibly modify them to be applicable and acceptable upstream", "personal time and energy to see this through", "willingness to jump through any hoops required to be able to contribute code to the GCC project", and it's just possible that nobody has yet satisfied all those preconditions. I was just (implicitly) bemoaning that. > If they're specific to the NetBSD configuration, then they should get > accepted right away, as long as basic stuff such as code formatting is > correct, as it's NetBSD developers who are the experts here after all. > > If they apply to generic MIPS stuff or the middle end, then things may > be a bit more involving, and in particular there has been no active MIPS > GCC port maintainer recently. But things can be sorted regardless, as > long as they get actually posted. There are people on the gcc-patches > mailing list who have MIPS experience, myself including, and for the > middle end we have active general maintainers. Understood. I'm just hoping someone could take this up as a challenge -- a "worthy cause" so to speak, as it ideally ought to reduce our own maintenance burden when new gcc versions are to be integrated into our own code base. Here's hoping... Best regards, - HÃ¥vard