[patch] --enable-dynamic-string default for mingw-w64 v2

[Kai Tietz]

2011/10/1 Pedro Alves <pedro@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