This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Maintainer tools
- To: 'Geoffrey Keating' <geoffk at geoffk dot org>
- Subject: Maintainer tools
- From: Bruce Korb <bkorb at allegronetworks dot com>
- Date: Mon, 16 Apr 2001 13:36:50 -0700
- Cc: "'gcc at gcc dot gnu dot org'" <gcc at gcc dot gnu dot org>, "'rms at gnu dot org'" <rms at gnu dot org>
Geoff wrote:
> So, it is not just "maintainers", it is all users
> who must be able to rebuild the program from source.
In the context of fixincludes, we are talking about
all those developers who are changing the fix definitions,
work on Windows boxes and are unable or unwilling to
rebuild fixincl.x on a separate platform. I do not
believe this to be a large class of people.
So, anyway, we got lotsa choices:
1. Continue as we are (AutoGen 4.x for fixincludes &
the current 5.x for everything else). This seems
not to be a big deal. fixincludes does not exactly
stretch AutoGen, so I don't need to diddle with it
very much.
2. Get a cut-down Guile working on Win-NT (under CygWin?)
so I can port AG-5.x
3. Require the above class of developers have access to
a Guile-enabled box.
4. Disable include fix hacking on Windows. (Don't we already
disable include fixing?)
I think every person who ever hacked on inclhack.def contacted
me first. I think it safe to say that if the developer class
is non-empty, then it is certainly a group that can be counted
on one hand. I always figured #1 was easiest, which is why
I never brought it up before.
So, I vote for #1. I prefer #2, but someone has to get
Guile reliably working on Windows. #3 and/or #4 are ok by
me, too, but I won't make such a decision.
Regards,
Bruce