From: Stan Shebs <shebs@cygnus.com>
To: robert.hoehne@gmx.net
Cc: gdb-patches@cygnus.com, gdb@cygnus.com
Subject: Re: DJGPP support (was libgdb)
Date: Thu, 01 Apr 1999 00:00:00 -0000 [thread overview]
Message-ID: <199903142241.OAA09754@andros.cygnus.com> (raw)
In-Reply-To: <199903141217.EAA03450@cygnus.com>
From: Robert Hoehne <robert.hoehne@gmx.net>
Date: Sun, 14 Mar 1999 13:20:40 +0100
> But how is anybody supposed to know what can be changed and what not?
Of course nobody can imagine what the mainatainer
of GDB will do with the sources (except of course the mainatiner itself).
True, although if something is a documented requirement, maintainers
should be loath to remove it. I can't remember the last time a command
documented in the manual was taken out, for instance, even though there
are some pretty dubious things in there.
I really don't understand, why you are against such small changes
which doesn't affect any behaviour of GDB but which will help the
programming of others. (for instance simply moving the newly
introduced global variables from main.c to top.c)
I'm not personally against doing this, in fact it seems like an easy
and reasonable thing to do. However, I also need to be able to
document this adequately somewhere, so that the next ambitious person
who comes along doesn't unknowingly undo this change. For instance,
HP now has a newly-formed GDB group in Cupertino - how will they know
what they can change freely and what to leave alone?
I have leaned that already :-( But at this point I really don't understand,
why the the mainatainers of GNU tools nearly ever forget when introducing
new features, that there are also people, which use the GNU environment
for DOS called DJGPP where are some limitations exist. And as I have
heared, the GNU cdrom with DJGPP on it was a hit.
Sometimes I think, the GNU mainatiner have something against DJGPP.
I'm sorry if you have that impression, it's certainly not the case.
Hey, back when I was doing Mac ports, a lot of people disapproved of
*me*! so I know what it feels like to port to and support a
non-standard configuration.
But I'm glad you brought this issue up. For a long time, it has been
the policy of the FSF not to expend much effort on DOS support. For
instance, there is this bit in etc/standards.texi:
"As for systems that are not like Unix, such as MSDOS, Windows, the
Macintosh, VMS, and MVS, supporting them is usually so much work that it
is better if you don't."
Although later on there is this, in a discussion of packaging for
release:
"Try to make sure that all the file names will be unique on MS-DOS."
And as you say, DJGPP is a popular port of GNU, and is being actively
maintained.
Since I'm a portability fanatic, I'm all in favor of making GDB
support DJGPP, and making any changes necessary to enable this in the
standard version of GDB. However, since GDB includes modules like
readline and bfd, it's also important to have at least the GDB-related
package maintainers agree to support DJGPP, if not GCC, GAS, LD, etc.
I would also like to get the FSF coding standards modified. RMS owns
the standard, so you or DJ or somebody should send him mail pointing
out that the standards would seem to discourage support for packages
like DJGPP, and could he please modify it to provide better guidance
for maintainers on this point.
Stan
WARNING: multiple messages have this Message-ID
From: Stan Shebs <shebs@cygnus.com>
To: robert.hoehne@gmx.net
Cc: gdb-patches@cygnus.com, gdb@cygnus.com
Subject: Re: DJGPP support (was libgdb)
Date: Sun, 14 Mar 1999 14:41:00 -0000 [thread overview]
Message-ID: <199903142241.OAA09754@andros.cygnus.com> (raw)
Message-ID: <19990314144100.ThYwJg8ZV7ELN9d8abvMZ0rcoQoSYP8RfcBptO59O5o@z> (raw)
In-Reply-To: <199903141217.EAA03450@cygnus.com>
From: Robert Hoehne <robert.hoehne@gmx.net>
Date: Sun, 14 Mar 1999 13:20:40 +0100
> But how is anybody supposed to know what can be changed and what not?
Of course nobody can imagine what the mainatainer
of GDB will do with the sources (except of course the mainatiner itself).
True, although if something is a documented requirement, maintainers
should be loath to remove it. I can't remember the last time a command
documented in the manual was taken out, for instance, even though there
are some pretty dubious things in there.
I really don't understand, why you are against such small changes
which doesn't affect any behaviour of GDB but which will help the
programming of others. (for instance simply moving the newly
introduced global variables from main.c to top.c)
I'm not personally against doing this, in fact it seems like an easy
and reasonable thing to do. However, I also need to be able to
document this adequately somewhere, so that the next ambitious person
who comes along doesn't unknowingly undo this change. For instance,
HP now has a newly-formed GDB group in Cupertino - how will they know
what they can change freely and what to leave alone?
I have leaned that already :-( But at this point I really don't understand,
why the the mainatainers of GNU tools nearly ever forget when introducing
new features, that there are also people, which use the GNU environment
for DOS called DJGPP where are some limitations exist. And as I have
heared, the GNU cdrom with DJGPP on it was a hit.
Sometimes I think, the GNU mainatiner have something against DJGPP.
I'm sorry if you have that impression, it's certainly not the case.
Hey, back when I was doing Mac ports, a lot of people disapproved of
*me*! so I know what it feels like to port to and support a
non-standard configuration.
But I'm glad you brought this issue up. For a long time, it has been
the policy of the FSF not to expend much effort on DOS support. For
instance, there is this bit in etc/standards.texi:
"As for systems that are not like Unix, such as MSDOS, Windows, the
Macintosh, VMS, and MVS, supporting them is usually so much work that it
is better if you don't."
Although later on there is this, in a discussion of packaging for
release:
"Try to make sure that all the file names will be unique on MS-DOS."
And as you say, DJGPP is a popular port of GNU, and is being actively
maintained.
Since I'm a portability fanatic, I'm all in favor of making GDB
support DJGPP, and making any changes necessary to enable this in the
standard version of GDB. However, since GDB includes modules like
readline and bfd, it's also important to have at least the GDB-related
package maintainers agree to support DJGPP, if not GCC, GAS, LD, etc.
I would also like to get the FSF coding standards modified. RMS owns
the standard, so you or DJ or somebody should send him mail pointing
out that the standards would seem to discourage support for packages
like DJGPP, and could he please modify it to provide better guidance
for maintainers on this point.
Stan
next prev parent reply other threads:[~1999-04-01 0:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-08 7:10 No Subject Andris Pavenis
1999-03-08 11:15 ` none Jim Blandy
1999-04-01 0:00 ` libgdb (was none) Robert Hoehne
1999-03-08 14:31 ` Robert Hoehne
1999-04-01 0:00 ` Stan Shebs
1999-03-10 15:39 ` Stan Shebs
1999-03-10 16:29 ` Todd Whitesel
1999-04-01 0:00 ` Todd Whitesel
1999-03-14 4:18 ` Robert Hoehne
1999-04-01 0:00 ` Robert Hoehne
1999-04-01 0:00 ` Stan Shebs [this message]
1999-03-14 14:41 ` DJGPP support (was libgdb) Stan Shebs
1999-04-01 0:00 ` none Stan Shebs
1999-03-08 13:09 ` none Stan Shebs
1999-03-09 12:54 ` none Robert Hoehne
1999-04-01 0:00 ` none Robert Hoehne
1999-04-01 0:00 ` none Jim Blandy
[not found] ` <99031011141900.03735.cygnus.patches.gdb@hal>
1999-03-10 16:31 ` libgdb.a Andrew Cagney
1999-04-01 0:00 ` libgdb.a J.T. Conklin
1999-03-11 14:29 ` libgdb.a J.T. Conklin
1999-04-01 0:00 ` libgdb.a Andrew Cagney
1999-04-01 0:00 ` libgdb.a Todd Whitesel
1999-03-10 16:56 ` libgdb.a Todd Whitesel
1999-03-11 12:40 ` libgdb.a Stan Shebs
1999-04-01 0:00 ` libgdb.a Stan Shebs
1999-04-01 0:00 ` libgdb.a Andris Pavenis
1999-03-11 0:27 ` libgdb.a Andris Pavenis
1999-04-01 0:00 ` libgdb.a Andris Pavenis
1999-03-10 1:14 ` libgdb.a Andris Pavenis
1999-04-01 0:00 ` No Subject Andris Pavenis
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=199903142241.OAA09754@andros.cygnus.com \
--to=shebs@cygnus.com \
--cc=gdb-patches@cygnus.com \
--cc=gdb@cygnus.com \
--cc=robert.hoehne@gmx.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