Hi Junio, On Mon, 17 Jun 2019, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Fri, 14 Jun 2019, Junio C Hamano wrote: > > > >> * js/gcc-8-and-9 (2019-06-13) 4 commits > >> - config: avoid calling `labs()` on too-large data type > >> - winansi: simplify loading the GetCurrentConsoleFontEx() function > >> - kwset: allow building with GCC 8 > >> - poll (mingw): allow compiling with GCC 8 and DEVELOPER=1 > >> > >> Code clean-up for new compilers. > >> > >> The 'kwset' one may want to be discussed a bit longer. Perhaps > >> merge the other three earlier to 'next' and then to 'master' > >> separately? > > > > Or just take the kwset one with an adjusted commit message because it may > > turn out that the kwset update will be blocked for a while because of > > licensing issues? > > Sorry, but I do not understand why you'd want to "take" one that you > suspect may be blocked for a while. I'd rather see us unblock the > other ones that are unproblematic, without taking them hostage, > which was what I meant. My apologies for causing confusion. What I *tried* to suggest is to take my minimal `kwset: allow building with GCC 8` together with the other three, as it fixes the build. Without it, the build is not fixed under `DEVELOPER=1`, it is still broken. This would prevent me from upgrading GCC in Git for Windows' SDK to GCC v8 or v9, as that SDK is used to run all the CI builds. Sure, having this small wrapper around `xmalloc()` would be a less elegant solution than the alternative (i.e. synchronize our `kwset` with upstream). But that alternative will take substantially longer to stabilize, and that would block the GCC upgrade substantially longer. And I am quite confident that Gábor (or is it Szeder?) will be very able to rebase their changes on top of that small compile fix. That's all I meant to say. Ciao, Dscho
