RFC: splitting gnat out of gcc-defaults?
The time when I will switch the default Ada compiler from gnat-4.3 to gnat-4.4
approaches. I am revisiting gcc-defaults and it seems overly complex to me.
I am therefore considering splitting the gnat source package out of
gcc-defaults and am looking for reasons why I should not do that.
gcc-defaults should be as complex as necessary and as simple as possible; I
feel it fails in this respect by being more complex than necessary:
- gnat-x.y is a separate package from gcc-x.y, therefore there is no reason
why gnat should be tied with gcc or g++. But the current situation requires
that each upload of a new gcc, g++, requires a simultaneous upload of gnat.
- As a consequence, gcc-defaults requires labor-intensive maintenance of
variables (e.g. REL_NO_441 and friends, REQV_44 and friends, REQV_GNAT, etc).
This maintenance and these variables are necessary only because all the
defaults are tied together in a single package. I fail to see what higher
purpose they serve.
The binary gnat package has only one requirement: depend on whichever package
gnat-x.y is the default on each supported architecture. Everything else, to
me, is line noise.
I think that a new source package named gnat could meet the requirement much
more directly than gcc-defaults can. A new version of gnat would be
necessary only when changing the default Ada compiler or changing the list of
supported architectures (per the requirement). I think the dependency and
list of architectures can be maintained directly in the control file instead
of indirectly in a bunch of variables, without any adverse impact on
legibility or maintainability.
PS. My reasoning may also apply to gcj, gpc and gdc because they are built
separately but here I'm only talking about gnat. The relevant language
maintainers can choose to ignore me or follow suit.
Any objections?
--
Ludovic Brenta.
Reply to: