public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Mitchell <mark@codesourcery.com>
To: ian@zembu.com
Cc: rth@cygnus.com, binutils@sourceware.cygnus.com
Subject: Re: Patches for IRIX6 N32-ABI ld
Date: Thu, 01 Jul 1999 00:00:00 -0000	[thread overview]
Message-ID: <19990626140924Q.mitchell@codesourcery.com> (raw)
In-Reply-To: <19990626204616.9890.qmail@daffy.airs.com>

>>>>> "Ian" == Ian Lance Taylor <ian@zembu.com> writes:

    Ian> I'm not sure why you want to bother, probably because I
    Ian> haven't seen the rest of your patches.

    Ian> Why not have two macros, one for general SGI compatibility,
    Ian> namely the existing SGI_COMPAT, and one new one you can use
    Ian> to check just which sort of SGI compatibility you want for a
    Ian> particular BFD?

Your suggestion is clearly equally expressive, so it's not like
something can be done way and not the other.  So, if you insist on
doing things your way, it's not like we'll lose anything.

I assumed this to be non-controversial, and used things like
`SGI_COMPAT (abfd) == sct_irix6' throughout the rest of my patches.
So, changing this will require a bunch of extra work for me.  That's
not a great argument, but it's accurate.

Also, "general SGI compatibility" is not a very well-defined notion.
The whole reason this patch is necessary is that SGI_COMPAT turns on
some behavior that isn't true in IRIX6; things have changed.  They'll
probably change again if there's ever an IRIX7, etc.

So, saying `if (SGI_COMPAT (abfd))' is a maintenance headache anyhow.
(It certainly was for me, at least, when working on the code.)  My
change makes it possible to gradually obsolete this usage.  In
particular, there's no need to change any existing code, but, on the
other hand, it's easy to change conditions to express just what
versions of IRIX things are appropriate for.

I'm really not looking to get embroiled in line-edits, especially on
the first set of diffs that add up to 3000 lines.  So, I'll not argue
the decision any further; I'll just abide by your next reply.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

  reply	other threads:[~1999-07-01  0:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-01  0:00 Mark Mitchell
1999-07-01  0:00 ` Richard Henderson
1999-07-01  0:00   ` Mark Mitchell
1999-07-01  0:00     ` Ian Lance Taylor
1999-07-01  0:00       ` Mark Mitchell
1999-07-01  0:00         ` Ian Lance Taylor
1999-07-01  0:00           ` Mark Mitchell [this message]
1999-07-01  0:00             ` Ian Lance Taylor
1999-07-01  0:00               ` Mark Mitchell
1999-07-01  0:00             ` Richard Henderson
1999-07-01  0:00               ` Mark Mitchell

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=19990626140924Q.mitchell@codesourcery.com \
    --to=mark@codesourcery.com \
    --cc=binutils@sourceware.cygnus.com \
    --cc=ian@zembu.com \
    --cc=rth@cygnus.com \
    /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).