This is the mail archive of the mailing list for the GCC project.

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

Re: Ada files now checked in

On Sat, Oct 06, 2001 at 11:06:41AM -0400, 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.


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