This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Ada files now checked in
- To: dewar at gnat dot com
- Subject: Re: Ada files now checked in
- From: Zack Weinberg <zack at codesourcery dot com>
- Date: Sat, 6 Oct 2001 09:46:15 -0700
- Cc: bosch at gnat dot com, gcc at gcc dot gnu dot org, kenner at vlsi1 dot ultra dot nyu dot edu
- References: <20011006150641.D3083F28AE@nile.gnat.com>
On Sat, Oct 06, 2001 at 11:06:41AM -0400, dewar@gnat.com wrote:
> <<Also, if it will result in a significant simplification of the build
> process, it may be worth rewriting these tools in C.
> >>
>
> Maybe, but that's quite a bit of work. They are originally written
> using powerful pattern matching of SNOBOL4. This translates directly
> into Ada, using the GNAT.Spitbol.Patterns unit which provides
> exactly SNOBOL4 semantics pattern matching capabilities in Ada.
Yes, I noticed that. I am fairly confident they could be rewritten
using regular expressions, in say Perl. Perhaps we could stop there,
if you're okay requiring Perl (this is already the case for people
wishing to generate manpages). Or, translating a short Perl program
into C is not *that* hard.
> That does not mean that it is impossible to rewrite these in C, but
> it would introduce a definite additional burden of keeping these C
> tools in sync with the Ada ones (they do change every now and then
> when e.g. the form of the tree changes enough to affect these
> tools).
What, you want to keep the Ada tools around as well as the C or Perl
ones? That would be silly. We only need one version.
> I still think we should be able to build these without too much
> difficulty as part of the build process. TBD
I'm now wondering how much additional trouble it would be to require
the presence of the basic Ada runtime library as well as a bootstrap
compiler. That would not only make it easy to generate these tools,
it would permit us to separate the construction of the compiler from
the construction of the runtime. I think this would make it easier to
maintain both in the long run. The only real disadvantage is that you
wind up with a compiler binary linked against the previous version of
the runtime, but this is not a huge problem, and one can always relink
the binaries afterward.
zw