Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Christopher Faylor <me at cgf dot cx>]

On Thu, Sep 23, 2004 at 02:30:11AM -0400, Michael Chastain wrote:
>Christopher Faylor <me@cgf.cx> wrote:
>> MichaelC has indicated which systems support "rb".  Is there any way to
>> somehow figure out if this is supported for the whole list of supported
>> targets?
>
>That brings up a tough philosophical issue.  Well, okay, part of it
>is tough because it implies more work for me.
>
>There isn't a list of supported hosts or supported targets.

There is a list of targets which have maintainers, though.

>The software itself has "list of hosts and targets that somebody, at
>some time in the past, contributed at least some work towards."

Maybe we're talking about the same thing but if there are inactive
maintainers then we need to know about that don't we?  I know that there
are various levels of maintainership but it seems like you should be
able to poll a quorum of maintainers and get a ruling rather than
assuming that we have to be extremely conservative because people who
have volunteered to be target maintainers are not doing their job.

>The gdb-testers@ group records "somebody tested something and reported
>results in some way".  That's where the "more work for me" comes in:
>devising some standard meta-information for a test run (like a little
>XML file, that's what I use in my test bed), and then augmenting the
>test suite to generate gdb-test-run.xml on every run, and then having
>people mail that in, and then begging more people to report their
>results, and then writing "Terf II" to keep track of it all.

I'm not talking about testing.  I know I am a bad maintainer because
I don't run the test suite on cygwin on a periodic basis.  (and if
there was someone waiting in the wings to take over windows maintainership,
I'd happily pass the baton)  We're talking about making architectural
changes which have a simple "will this work (yes/no)" criteria.  I,
as a bad maintainer, would certainly respond to queries of that nature.

If we have maintainers who can't respond to these types of questions maybe
their targets should be deprecated.  Deprecation is the gdb way after all.

>The release criteria for gdb is "break main ; run works on unspecified
>platforms".
>
>> Or can we try going without the wrapper function and move
>> to a wrapper function when someone complains?
>
>For the second question, from a support point of view, I want something
>that (a) works on a lot of systems and (b) when it doesn't work on some
>system, it's an obvious 1-line patch to work around the problem.  So I
>don't like "no wrapper function but then change the code when someone
>shows up with a weird system".

I thought that fopen not working would be a pretty obvious problem with
a pretty obvious fix.

>Personally I like wrappers for ease of porting.  It doesn't bug me to
>see gdb_fopen + fopen on the call stack.

I certainly understand the utility of wrapper functions.  That's pretty
much all that Cygwin is, after all.

>I don't think that "rb" versus "r" can be autoconf'ed.  The gdb
>configure script would need to execute a host program to figure out
>whether "rb" is supported or not, and that won't work if build != host.
>Or maybe I'm wrong about that and there's some way to do it.

I think you're right.  I don't see how we could tell.  That shoots down
my "check for PATH separator" idea, too, I think.

I guess the thing that sticks in my craw is the continual need to stand
on our heads to accommodate that one theoretical system that just might
not work as required.  So, you have to invent a function called
"fopen_wrapper" which is essentially the same thing as "fopen" and that
leaves a programmer to puzzle out why there is an fopen_wrapper rather
than an fopen.

I pointed out that the way this is handled with open now is to define
O_BINARY as required.  It seems like if we are going to be consistent
that open and fopen should use the same mechanism.  So if we go with the
wrapper function for fopen, I think we should do the same for open.

cgf