[gentoo-dev] fortran-2.eclass EAPI-8 support

[gentoo-dev] fortran-2.eclass EAPI-8 support

[Marek Szuba]

On the plus side, nothing in here that requires changing to work with
the new EAPI. On the minus side, we still got many EAPI-5 and 6
consumers of this eclass in the tree so no chance of dropping support
for these two at this time.

[gentoo-dev] [PATCH] fortran-2.eclass: support EAPI 8

[Marek Szuba]

Signed-off-by: Marek Szuba <marecki@gentoo.org>
---
 eclass/fortran-2.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 0bb00f475a2..9d0c71703e4 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -7,7 +7,7 @@
 # @AUTHOR:
 # Author Justin Lecher <jlec@gentoo.org>
 # Test functions provided by Sebastien Fabbro and Kacper Kowalik
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @BLURB: Simplify fortran compiler management
 # @DESCRIPTION:
 # If you need a fortran compiler, then you should be inheriting this eclass.
@@ -31,7 +31,7 @@ inherit toolchain-funcs
 case ${EAPI:-0} in
 	# not used in the eclass, but left for backward compatibility with legacy users
 	5|6) inherit eutils ;;
-	7) ;;
+	7|8) ;;
 	*) die "EAPI=${EAPI} is not supported" ;;
 esac
 
-- 
2.31.1

Re: [gentoo-dev] fortran-2.eclass EAPI-8 support

[Ulrich Mueller]

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

>>>>> On Wed, 14 Jul 2021, Marek Szuba wrote:

> On the plus side, nothing in here that requires changing to work with
> the new EAPI. On the minus side, we still got many EAPI-5 and 6
> consumers of this eclass in the tree so no chance of dropping support
> for these two at this time.

Shouldn't virtual/fortran go into BDEPEND in EAPIs 7 and 8?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] fortran-2.eclass EAPI-8 support

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 414 bytes --]

On 2021-07-14 13:02, Ulrich Mueller wrote:

> Shouldn't virtual/fortran go into BDEPEND in EAPIs 7 and 8?

Good point! I've created https://bugs.gentoo.org/802153 so that we do 
not lose track of this, that said it is beyond the scope of the issue at 
hand (the eclass will not behave any differently here under EAPI 8 than 
it does under EAPI 7) so I'll leave my current patch as it is.

-- 
Marecki


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] fortran-2.eclass EAPI-8 support

[Sam James]

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



> On 14 Jul 2021, at 13:43, Marek Szuba <marecki@gentoo.org> wrote:
> 
> On 2021-07-14 13:02, Ulrich Mueller wrote:
> 
>> Shouldn't virtual/fortran go into BDEPEND in EAPIs 7 and 8?
> 
> Good point! I've created https://bugs.gentoo.org/802153 so that we do not lose track of this, that said it is beyond the scope of the issue at hand (the eclass will not behave any differently here under EAPI 8 than it does under EAPI 7) so I'll leave my current patch as it is.
> 

But to introduce a fix, isn't it a _lot_ easier to do it at the point of a new EAPI? What's the rush to add it if we're not ensuring we're using the new features correctly?

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] fortran-2.eclass EAPI-8 support

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 769 bytes --]

On 2021-07-16 22:50, Sam James wrote:

> But to introduce a fix, isn't it a _lot_ easier to do it at the point of a new EAPI?

In general, IMHO only if we intend to preserve the old (incorrect) 
behaviour for older EAPIs - which in this particular case was not needed 
because I cannot think of someone having come to rely on the fact EAPI-7 
ebuilds inheriting fortran-2 could not be cross-compiled.

In this particular case, the patch I submitted for review earlier on 
today explicitly mentions neither EAPI 7 nor EAPI 8 - so not really, no. 
In fact, I would argue that in case of eclasses requiring more work to 
adapt to a new EAPI trying to fix old bugs at the same time could 
distract reviewers from the EAPI adaptation itself.

-- 
Marecki


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]