This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: (Fwd) Re: Absolute paths in BFD


   Date: Fri, 28 Apr 2000 18:05:16 -0400 (EDT)
   From: Eli Zaretskii <eliz@delorie.com>

   > Date sent:      	26 Apr 2000 15:31:54 -0700
   > From:           	Ian Lance Taylor <ian@zembu.com>
   >
   >    > A few months ago someone posted a series of patches to handle this very 
   > >
   >    problem.  See: > >
   >    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00584.html >
   >    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00585.html >
   >    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00586.html >
   >    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00587.html >
   >    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00588.html >
   >    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00589.html >
   >    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00590.html
   > 
   > I feel like I would rather copy the names that gcc uses:
   > IS_DIR_SEPARATOR, IS_PATH_SEPARATOR, HAVE_DOS_BASED_FILE_SYSTEM, etc.
   > 
   > In fact, I said that a long time ago:
   >     http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00596.html

   In the conversation that followed the above message, I told you that
   the macros I used in my patches are used in other GNU projects, like
   Texinfo and Grep.  You then said that you were willing to accept them
   as well.  So I patiently waited for the patches to be
   reviewed/accepted.

Whoops, sorry.  I forgot about that.

binutils maintenance is not working well these days.  I apologize.  I
simply don't have time to fully consider patches.

   If you want to reconsider that decision, I could rework the patches
   (although I don't understand why the GCC's way of parameterizing these
   macros is better than that of the other projects).

gcc's way is better because gcc and the binutils share the directories
include and libiberty.  You've added a file to include, for example;
that file should really be added to the gcc repository as well.

   But please give me
   some hope that the new patches will be reviewed and committed to the
   Binutils CVS tree somewhat faster than the previous ones.  It can be
   quite frustrating to go through all the coding and testing once again,
   only to see the patches stuck in the queue for another 6 months ;-).

I wish I could give you that hope, but I can't.  If the patch is
simple, I can approve it quickly.  Otherwise, some other maintainer
has to do it.

   > Testing something like DOSISH_FILENAMES in binutils/ar.c looks wrong.
   > DOSISH_FILENAMES is meaningful on the host, but binutils/ar.c deals
   > with files that are specific to the target.

   The code fragments conditioned on DOSISH_FILENAMES in ar.c do not
   contradict the original code (which considers forward slashes only),
   they _augment_ it.  That is, the code looks for forward slashes, and
   then for backslashes.

   So I don't think there's a problem here.  But if you think this might
   be a problem for Windows-hosted development environments whose targets
   can be harmed by this code, I could make those fragments conditioned
   on __DJGPP__, where the host and the target are the same.

Good point.

   > The changes to binutils/strings.c and gprof/gmon_io.h assume that any
   > system with O_BINARY has setmode and isatty, and I don't think that's
   > true.

   Please suggest an alternative.  Would you like a separate definition
   for setmode?

   As for isatty, I'm not aware of a C library that doesn't have it.  But
   if you would like a separate macro for it, I can do that, too.

Yes, I think setmode could be a problem.  It might be best to test for
that separately.

Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]