2017-05-17 16:10 GMT+02:00 David Grayson <[email protected]>: > Here's the sed command again, without bad line wrapping: > > https://gist.github.com/DavidEGrayson/ee9796a900eedda3d6b7c8f2324793a4 > > --David
This sed command is nice, but nothing to be recommended for our users. Driver buiding is for sure the more rare case, and most users won't be interested in that pretty much. For those which are, this might be a way. Once again, why we include by default driverspecs.h ? Is that of any meaning, beside for people using ddk? > On Wed, May 17, 2017 at 7:08 AM, David Grayson <[email protected]> > wrote: >> A GCC maintainer has spoken up and said they will accept a patch to >> rename __in and __out to other things: >> >> https://gcc.gnu.org/ml/gcc-help/2017-05/msg00152.html Sure, saw that, but this is not the point. See above. >> As soon as I have a bit of free time, I will submit such a patch to >> them, though LH_Mouse might beat me to it. >> >> So in the long term, we can have __in and __out, and we can have >> compatibility with libstdc++v3. I'd rather not change mingw-w64. Iff libstdc++ will be modified, then we can enable these include with a gcc version check. But it is nothing mandatory to use up to date gcc version, so again, this is a pie in the sky, nothing else. >> In the MSYS2 project, we've already dealt with this issue by >> generating a patch for libstdc++v3 using this command I put together: What msys2 hacks, is in msys2's responsibility. On mingw-w64 we can't do such things, as we have to deal with a much wider user range, and not just for one environment. >> sed -ri 's/\b(__in|__out)\b/_&/g' $(egrep -rl '\b(__in|__out)\b' >> libstdc++-v3/{include,config}) >> >> If you are compiling your own mingw-w64 toolchain, you should be >> capable of just running that line of code before building GCC to fix >> the name collision. >> >> If you are a user who is using a broken mingw-w64 toolchain, you >> should tell the people who built it about the line above, but in the >> meantime, you can edit driverspecs.h with a text editor and uncomment >> the lines that define __in and __out. >> >> So I think the status quo is totally fine. >> >> But if we do change mingw-w64, I can revert your change in my builds, >> and that works too, and it's just as easy as getting other toolchain >> builders to run the sed command. If we do change mingw-w64, what >> would be the timeline for reverting that change? Would we wait until >> the offending versions of libstdc++ have been replaced by fixed stable >> for versions for, say, 5 years? >> >> --David Grayson >> >> On Wed, May 17, 2017 at 6:18 AM, Mateusz <[email protected]> wrote: >>> W dniu 2017-05-17 o 13:10, Kai Tietz pisze: >>>> Hello, >>>> >>>> I dislike such a change. As if somebody wants to driverspec.h, op >>>> will need these symbols defined. Otherwise build will badly fail. >>>> So this brings us back to the reasoning of this ... adding to >>>> specstrings.h the include of driverspecs.h. IMHO this shouldn't be >>>> done always. The best solution would be something like to include >>>> driverspecs.h in specstring.h only, if user intends to use ddk. >>>> Otherwise we shouldn't include this header at all. >>>> >>>> Any thoughts? >>>> >>>> Regards, >>>> Kai >>> >>> We could roll back commit [b7f44b]. >>> >>> Now there are new commits and this should be fixed. >>> >>> Mateusz >>> >>> >>> >>>> >>>> >>>> 2017-05-17 12:34 GMT+02:00 Mateusz <[email protected]>: >>>>> We really should do something with '__in' and '__out' from driverspecs.h. >>>>> >>>>> Please review. >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Mingw-w64-public mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Mingw-w64-public mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Mingw-w64-public mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public Cheers, Kai ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
