Yes, let's fix it. I'm very grateful to you and everyone else who has kept the MinGW build running; and I'd like to keep you... well as happy as you can be while supporting an esoteric build target that's inconvenient for you.
With regards to backouts, when sheriffs have asked, my response has been that if something is directly attributable to a patch and it doesn't look like it's a MinGW problem (like the recent missing dwrite_3.h issue) - I'd appreciate a backout. This is mostly selfishness, the times there was no backout and MinGW starts perma-failing it's been up to me to diagnose the issue and fix it; only once have MinGW patches been needed. If that needs to change, alright. As far as what we can do to make it easier. I think/hope MinGW isn't a strain on TC; there are no tests associated, it even skips the normal check-tests that run for other build jobs; and it runs on a small Linux box so it should be the cheapest option for us. It could build faster though; sccache doesn't work for it and I haven't been able to figure out why (Bug 1411212). > But when it comes to the header case mismatch issue, we could automate this. > Would it be possible for us to write some code to automatically detect these > case > discrepancies and automatically land corrections? Where would be the right > place > for something like that to live? I'd be happy to build something that does this. I don't know what's possible or where it should live though. It's probably easy for me to add it to the lint job, wherever that is. I might be able to integrate it into the new MozReview Static Analysis thing. I don't know if it's possible, or how, to automatically land corrections* but maybe? Also, not that this is a solution for today but as I mentioned in the first email - my hope is that some of this becomes easier with a move to clang. It won't address everything, but I hope at least some of the MinGW pain is lessened by a mingw-clang option. I could see us patching our mingw-clang build to work with case insensitive includes for example; and the __try/__except issues we have would go away also. There's a few paths forward on this front. One using a mingw-clang, one using clang-cl on Linux. The work on the first one is happening in Bug 1390583. -tom * and I am nervous about giving some new system the ability to automatically land code On Tue, Feb 6, 2018 at 5:36 PM, Aaron Klotz <akl...@mozilla.com> wrote: > I'd like to follow up on this old thread to discuss what we can do about > improving the mingw developer experience for people doing Windows-centric > stuff. > > I've had several patches backed out over the past month because of mingw > header files differing in case from the headers distributed by the official > Windows SDK. Frankly, it's a waste of developer time to be dealing with > this. This is particularly frustrating in the case of autoland, where we > can't just push our own follow-up patches. > > Those of us who are trying to do Windows-specific stuff are effectively > stuck simultaneously coding to two similar, yet still different, SDKs, being > built across two distinct operating systems that differ in case sensitivity. > > In some cases, discrepancies between the SDKs are inevitable: Perhaps mingw > hasn't kept up with the official Windows SDK and some headers/APIs are > missing. We just have to take those as they come. > > But when it comes to the header case mismatch issue, we could automate this. > Would it be possible for us to write some code to automatically detect these > case discrepancies and automatically land corrections? Where would be the > right place for something like that to live? > > Those of us locally building on Windows already have enough annoyances with > the build as-is, so I don't consider "you should be building locally on both > Windows/MSVC and Linux/mingw simultaneously" to be a reasonable option. Nor > do I consider always pushing mingw jobs to try to be ideal: it delays the > landing of patches and potentially wastes build machine time, compared to an > automated lint. > > Furthermore, can we clarify whether mingw is currently a tier 1 or tier 2 > platform? Earlier in this thread, mingw was denoted as tier 2 (and it still > shows up as tier 2 on treeherder), yet sheriffs are backing out patches when > mingw bustage occurs. Tor is important, so of course we want to make our > best effort to ensure that mingw isn't broken, but this "tier 2 but really > tier 1" state is not helpful. > > I apologize for being curt, but this is becoming rather frustrating. > > Aaron > > > On Mon, Oct 9, 2017 at 10:14 AM, Tom Ritter <t...@mozilla.com> wrote: >> >> On Mon, Oct 9, 2017 at 10:31 AM, Philipp Wagner <n...@philipp-wagner.com> >> wrote: >> >> > Am 09.10.2017 um 07:31 schrieb Tom Ritter: >> > > As part of our work with Tor, we’ve been working on getting a >> > > MinGW-based >> > > build of Windows into TaskCluster. >> > >> > A maybe too obvious question from the side lines: Why is the Tor browser >> > cross-compiled and not using MSVC? >> > >> > >> Building on Linux allows Tor Browser (including its entire toolchain and >> dependencies) to be built deterministically and thus reproducibly using an >> entirely open source toolchain. (There are a few small exceptions but >> they're quite small.) >> >> Reproducible builds significantly reduce the trust inherent in an >> organization's build infrastructure and when recreated independently >> ensure >> that nothing unexpected was inserted into the final executable. Having the >> entire toolchain open source ensures that anyone who wants to inspect the >> code or reason about its behavior can do so. (And as I've learned in the >> past year Tor actually has a good amount of anonymous contributors reading >> the source code of its toolchain and reporting things.) >> >> You can read more about the philosophy behind this movement at >> >> https://blog.torproject.org/deterministic-builds-part-one-cyberwar-and-global-compromise >> https://reproducible-builds.org/ >> CCleaner is a good example of attackers backdooring compiled software. >> >> The next step, past reproducible builds, is Binary Transparency, which >> ensures that before an update is applied, it is publicly known, so >> attackers cannot surreptitiously subvert the update mechanism. Tor is >> exploring some avenues there. FLAME is a good example of attacking the >> update mechanism. >> >> I would describe Mozilla as 'curious' about reproducible builds (see >> https://bugzilla.mozilla.org/show_bug.cgi?id=885777); but we are actively >> working on Binary Transparency (see >> https://bugzilla.mozilla.org/show_bug.cgi?id=1341395). >> >> -tom >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
