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..
