public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: JonY <jon_y@users.sourceforge.net>
Cc: gcc-patches@gcc.gnu.org,
	"mingw-w64-developer@lists.sourceforge.net"
	<mingw-w64-developer@lists.sourceforge.net>
Subject: Re: [patch] --enable-dynamic-string default for mingw-w64 v2
Date: Sat, 01 Oct 2011 13:02:00 -0000	[thread overview]
Message-ID: <201110011401.52471.pedro@codesourcery.com> (raw)
In-Reply-To: <4E86F65E.3000002@users.sourceforge.net>

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

  reply	other threads:[~2011-10-01 13:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-01  6:04 JonY
2011-10-01  6:30 ` [Mingw-w64-developer] " Ozkan Sezer
2011-10-01  9:16 ` Paolo Carlini
2011-10-01  9:49   ` JonY
2011-10-01 10:10     ` Paolo Carlini
2011-10-01 11:10       ` JonY
2011-10-01 11:16         ` Paolo Carlini
2011-10-01 14:32           ` JonY
2011-10-06 12:55             ` JonY
2011-10-08 15:43               ` JonY
2011-10-08 16:11                 ` Paolo Carlini
2011-10-08 17:54                   ` Kai Tietz
2011-10-13 13:47                     ` JonY
2011-10-13 13:59                       ` Paolo Carlini
2011-10-13 14:09                         ` NightStrike
2011-10-13 14:33                         ` Kai Tietz
2011-10-01 10:34 ` Pedro Alves
2011-10-01 11:16   ` JonY
2011-10-01 13:02     ` Pedro Alves [this message]
2011-10-01 15:06       ` Kai Tietz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201110011401.52471.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jon_y@users.sourceforge.net \
    --cc=mingw-w64-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).