[gentoo-dev] gnatbuild.eclass refactoring: new/transitory eclass?

[George Shapovalov]

I am about to start a long-overdue refactoring of the gnat (Ada compilers) 
build system, governed by the gnatbuild.eclass. Given that nature of the 
packages concerned and, for quite some time, I was the only person brave 
enough to even touch this beast this probably does not concern too many 
people. However, since I am likely to produce some observable effects, such as 
introduction of a (possibly transitory) new eclass, I am giving a requisite 
heads-up here.

First a short but necessary introduction:
gnatbuild.eclass is a complex and ancient beast controlling the build of the 
two Ada compilers we have in the tree - gnat-gcc (by FSF) and gnat-gpl (by 
AdaCore). It has been created some 10 years ago, following the toolchain.eclas 
of then, long before even functions like src_prepare were envisioned and the 
term pms existed only in medical terminology. Correspondingly, it is composed 
of big blocks of code, not very modular and can benefit greatly of new 
practices.

The catch is that all the gnat-xxx ebuilds depend on it and replacing the 
eclass would require modifying all of the ebuilds at the same time. Given the 
typical adjustmentsto address gcc backend gets bumps and the differences 
between two implementations, doing a big, all-in-one change like that is a 
perfect recipe for disaster that would likely lead to total breakage of gnat 
build system and the project that is never complete at the same time. 
Therefore I am thinking to do it in a more usual and gradual manner: 

1. introduce a new eclass, say gnatbuild2.eclass, which will be new, 
refactored and much cleaned-up version of an existing gnatbuild.eclass

2. Update ebuilds independently to use the new eclass.

3. Stabilize new ebuilds and gradually phase out old ones. 

4. When old eclass is no longer necessary, remove it.

5. (optional) Rename new eclass to use old name and update all inherits in 
ebuilds correspondingly..


So, this is it for the heads-up. 
Now, here come two questions:

1.  Is there some kind of convention for such situations: should I go on with 
the optional step 5 when all is done or is the preference to keep old eclass 
forever?  I can see the rationale for keeping it forever in some cases (say 
for some very conservative core libs), but here this should not be necessary, 
this is just an internal detail of build system for these compilers..

2. Is there some standard naming scheme? Should the new eclass be called, say, 
gnatbuild2.eclass or gnatbuild-ng.eclass? Of course this only matters if old 
eclass is there to stay. If not I'll just call the transitory eclass something 
like gnatbuild-refactor.eclass for the duration of its existence..