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, 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. -- Pedro Alves
