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

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

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

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

On Thu, 2015-09-03 at 16:00 +0200, George Shapovalov wrote:
> 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..

I suggest gnatbuild-r1.eclass, that seems to be the most widely used
eclass versioning pattern. Some examples:

bash-completion.eclass → bash-completion-r1.eclass (2011)
distutils.eclass → distutils-r1.eclass (2012)
emboss.eclass → emboss-r1.eclass (2015)
git.eclass → git-2.eclass (2011) → git-r3.eclass (2013)
myspell.eclass → myspell-r2.eclass (2012)
office-ext.eclass → office-ext-r1.eclass (2013)
python.eclass → python-r1.eclass (2012)
qt4.eclass → qt4-r2.eclass (2009)

Other patterns:

java-utils.eclass → java-utils-2.eclass (2006)
mysql.eclass → mysql-v2.eclass (2011)
ruby.eclass → ruby-ng.eclass (2009)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

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

[Duncan]

Alexandre Rostovtsev posted on Fri, 04 Sep 2015 10:05:31 -0400 as
excerpted:

> On Thu, 2015-09-03 at 16:00 +0200, George Shapovalov wrote:
>> 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..
> 
> I suggest gnatbuild-r1.eclass, that seems to be the most widely used
> eclass versioning pattern. Some examples:
> 
> bash-completion.eclass → bash-completion-r1.eclass (2011)
> distutils.eclass → distutils-r1.eclass (2012)
> emboss.eclass → emboss-r1.eclass (2015)
> git.eclass → git-2.eclass (2011) → git-r3.eclass (2013)
> myspell.eclass → myspell-r2.eclass (2012)
> office-ext.eclass → office-ext-r1.eclass (2013)
> python.eclass → python-r1.eclass (2012)
> qt4.eclass → qt4-r2.eclass (2009)
> 
> Other patterns:
> 
> java-utils.eclass → java-utils-2.eclass (2006)
> mysql.eclass → mysql-v2.eclass (2011)
> ruby.eclass → ruby-ng.eclass (2009)

Just to add...

As the folks doing the git eclasses found out, bare generation numbers 
are all too easily confused with upstream version numbers -- git-2.eclass, 
is that for use with git-2*?  

Given that gentooers are already familiar with the -rN identifier from 
ebuilds and know that there it unambiguously indicates a gentoo revision, 
as opposed to upstream, the same idea was eventually borrowed for eclasses 
identifiers -- git-r3.eclass unambiguously indicates what git-2.eclass 
didn't, that it's the third /gentoo/ generation of git eclass, *not* just 
for /upstream/ git-v3 (when there is one).  (Xref eclasses such as qt4, 
kde4, qt5... where the number indicates upstream version.)

So -rN has become the standard gentoo-generation identifier for eclasses, 
meaning much the same thing as it does when used for ebuilds.  If you'll 
note, the other listed patterns are from 2011 or earlier, when the 
git-2.eclass experience proved its name a confusing mistake and 
effectively catalyzed the standardization around the -rN pattern that  
was apparently (based on the above dates) first used with qt4-r2.eclass 
in 2009.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Michael Haubenwallner]

Hi George,

On 09/03/2015 04:00 PM, George Shapovalov wrote:
> 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: 

Just wondering whether you are aware of https://bugs.gentoo.org/547358 already:

Although I'm not an Ada dev, as gcc upstream committer I've need to bootstrap
the Ada parts within gcc as well, but faced that neither AdaCore nor gnat-xxx
ebuilds provide a C,C++,Ada compiler. Given that AdaCore seems to not provide
anything up-to-date at all any more, my idea was to provide the recent FSF Ada
compiler via toolchain.eclass only.

Thanks!
/haubi/