2011/10/1 Pedro Alves <pe...@codesourcery.com>: > On Saturday 01 October 2011 12:15:42, JonY wrote: >> On 10/1/2011 18:33, Pedro Alves wrote: >> > On Saturday 01 October 2011 07:03:35, JonY wrote: >> >> Hi, >> >> >> >> I followed Paolo's suggestion with the os_defines.h trick. I duplicated >> >> os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any >> >> built-in defines to tell the 2 apart unless you include some headers >> >> like _mingw.h. >> > >> > Are we really introducing a bunch of duplication between >> > os/mingw32/ and os/mingw32-w64/ ? I didn't see the part that adds the >> > new dir and does all those copies in the patch; where is it? Or have >> > I missed something? Can't we make configure add >> > -D__IM_REALLY_W64_YOU_KNOW to CFLAGS instead? Or come up with a way >> > to point libstd++ to pick up a new mingw32/os_defines_w64.h file instead >> > that does: >> > >> > #include "os_defines.h" >> > // mingw-w64 should use fully-dynamic-string by default >> > #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING >> > #define _GLIBCXX_FULLY_DYNAMIC_STRING 1 >> > #endif >> > >> >> The new files are missing from svn diff because I used svn copy to copy >> the directories, svn diff didn't show them, should I use something else >> instead? > > So that'd be a patch with its own ChangeLog, as your patch applies on > top of that already. > >> IMHO, mingw.org and mingw-w64 may or may not diverge further in the >> future, so sprinkling defines to codes isn't very good in the long run. > > "may or may not" is key. We don't know the future, but we know > the present. We do know that code duplication is bad. I can just > as well say,
Well, this situation isn't ideal. It might be that one day mingw.org and mingw-w64 venture come more near in feature-set. But this is for sure more a long-term issue and not a short or medium-term thing. > IMHO, mingw.org and mingw-w64 may or may not diverge further in the > future (ideally they wouldn't), so adding code duplication when > we only need one define isn't very good in the long run. > > But I'm not a maintainer, so I shall just go away. Well, we diverge already more and more. I plan to provide for libstdc++ some new printf/scanf API features for wide and ascii variants, which is present in mingw-w64 venture, but not in mingw.org venture. We have also other divergencies in other feature-set, which lead already to an add-on header in gcc for specific mingw-w64 targets. Kai