[gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran

[gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran

[justin]

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

Hi,

I want to add following change to fortran-2.eclass to achieve more
simpler usage.

The patch will make the eclass depend on virtual/fortran so that no
manual addition is needed.
Two exception are present, a) the ebuild has the USE flag fortran, then
we check for that, or b) the FORTRAN_OPTIONAL variable is set, which
leaves the control to the ebuild (e.g. for cases like "lapack? (
virtual/fortran )").

This is the best coverage of the use cases present, because

* most ebuild using the eclass want to have a fortran compiler
* most other trigger optional fortran support through USE=fortran
* only minor have different USE for this purpose (e.g. numpy)

Thanks for comments,

Justin

[-- Attachment #1.2: fortran.patch --]
[-- Type: text/plain, Size: 1008 bytes --]

Index: fortran-2.eclass
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/fortran-2.eclass,v
retrieving revision 1.11
diff -u -B -r1.11 fortran-2.eclass
--- fortran-2.eclass	7 Oct 2012 14:53:43 -0000	1.11
+++ fortran-2.eclass	7 Oct 2012 17:18:28 -0000
@@ -35,6 +35,26 @@
 
 inherit eutils toolchain-funcs
 
+# @ECLASS-VARIABLE: FORTRAN_OPTIONAL
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Set this before inheriting the eclass, if your package has an optional 
+# fortran support, which is triggered by a different USE flag than 'fortran'.
+# This requires manual handling of the dependency on virtual/fortran.
+#
+# If unset, the dependency on virtual/fortran is added directly.
+
+if [[ -n ${FORTRAN_OPTIONAL} ]]; then
+	if in_iuse fortran; then
+		DEPEND="fortran? ( virtual/fortran )"
+	else
+		DEPEND="virtual/fortran"
+	fi
+fi
+
+RDEPEND="${DEPEND}"
+
+
 # @FUNCTION: _write_testsuite
 # @INTERNAL
 # @DESCRIPTION:

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

[gentoo-dev] Re: RFC: fortran-2.eclass to depend on virtual/fortran

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/07/2012 01:20 PM, justin wrote:
> Hi,
> 
> I want to add following change to fortran-2.eclass to achieve more 
> simpler usage.
> 
> The patch will make the eclass depend on virtual/fortran so that
> no manual addition is needed. Two exception are present, a) the
> ebuild has the USE flag fortran, then we check for that, or b) the
> FORTRAN_OPTIONAL variable is set, which leaves the control to the
> ebuild (e.g. for cases like "lapack? ( virtual/fortran )").
> 
> This is the best coverage of the use cases present, because
> 
> * most ebuild using the eclass want to have a fortran compiler *
> most other trigger optional fortran support through USE=fortran *
> only minor have different USE for this purpose (e.g. numpy)
> 
> Thanks for comments,
> 
> Justin
> 

You cannot check the value of IUSE in global scope in an eclass, as at
least portage actually unsets it before sourcing an eclass (also, it
is not defined in PMS what value IUSE would have at that point).  You
also got a conditional backwards -- if you don't set FORTRAN_OPTIONAL
with that patch, then *nothing* gets appended to DEPEND -- if you do
set it, then DEPEND="virtual/fortran" will always be set (with your
current logic).

- --
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQcb2UAAoJELHSF2kinlg4jQMP/Rt4UJBDCPE6lJyEoHzTp60l
GapkNJRpBjiihYZ1n5pAtBpUvbKqgAo4zvvXX2AvLDfUazcpnPh3ZdW8Gc8JtycF
cvCrUoUfV+0MY29DEcvL0tV5wX9ha5B5YEurR/zoPQ29V6eJqho21G+GZJ6L4Mdj
rIcTRDf4izaDqiunRDRQp51udYEnAQLR8I9FAA4ybh1Dd536xmnm3jdDkGtpvgrW
15vWMdr8ETkmy5eK59K/iP6U4IzPldBXff+rKyIlss/D6CNrXI0WqeYY2PdFUHGk
E+C4Sqx633AjevfS04c+6feAcsS3gIpZWVuzA0BZSXeFUFB7Cdph1RwHpLOYM50Q
OoGi9/ha2llD3J/iS+76ddlP953ZfRrt3ZfjWzCaTsec73AA/srBuaxtoiOGjC/r
5DecDgL6OrOPJdad29VE1B/xEkccj+C7/YYXtwxsS2MzzL5oi8hpnnrLH/wmqOK9
Y/uf1H02swPu6m+ER8De/5KAgKc7LCaTmgvZVKetZHgZw2TqG0dwAwJ7FickiE/W
49yfc6wf8kQGtaH/BqHb+ja0T18y90jHhrexaGPK7mSU2LCzvQnMHDMAIEuSRzgz
iM8JPsqJ6Jwc/dD3MMW7WKWf/aSP1fy+wJXGaK4eI25U5LmPzmNn7E68W1WUjKRc
5pfLsVRThwg2Md1UjlDO
=P5yK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: fortran-2.eclass to depend on virtual/fortran

[justin]

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

On 10/7/12 7:36 PM, Jonathan Callen wrote:
> On 10/07/2012 01:20 PM, justin wrote:
>> Hi,
> 
>> I want to add following change to fortran-2.eclass to achieve more 
>> simpler usage.
> 
>> The patch will make the eclass depend on virtual/fortran so that
>> no manual addition is needed. Two exception are present, a) the
>> ebuild has the USE flag fortran, then we check for that, or b) the
>> FORTRAN_OPTIONAL variable is set, which leaves the control to the
>> ebuild (e.g. for cases like "lapack? ( virtual/fortran )").
> 
>> This is the best coverage of the use cases present, because
> 
>> * most ebuild using the eclass want to have a fortran compiler *
>> most other trigger optional fortran support through USE=fortran *
>> only minor have different USE for this purpose (e.g. numpy)
> 
>> Thanks for comments,
> 
>> Justin
> 
> 
> You cannot check the value of IUSE in global scope in an eclass, as at
> least portage actually unsets it before sourcing an eclass (also, it
> is not defined in PMS what value IUSE would have at that point).  You
> also got a conditional backwards -- if you don't set FORTRAN_OPTIONAL
> with that patch, then *nothing* gets appended to DEPEND -- if you do
> set it, then DEPEND="virtual/fortran" will always be set (with your
> current logic).
> 
> 

Regarding your first point I copied the behavior from the
toolchain.eclass and I thought it would work. Testing it, I see you are
right. Any suggestion how to check for a USE being IUSE in an eclass?

NAd your second point is completely right. I fix this when we sorted out
the USE check.

Thanks
Justin


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

Re: [gentoo-dev] Re: RFC: fortran-2.eclass to depend on virtual/fortran

[Ciaran McCreesh]

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

On Sun, 07 Oct 2012 19:58:04 +0200
justin <jlec@gentoo.org> wrote:
> Any suggestion how to check for a USE being IUSE in an eclass?

You can't. See the zillion previous discussions on this subject.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: RFC: fortran-2.eclass to depend on virtual/fortran

[Xavier Miller]

Le Sun, 07 Oct 2012 13:36:20 -0400,
Jonathan Callen <abcd@gentoo.org> a écrit :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 10/07/2012 01:20 PM, justin wrote:
> > Hi,
> > 
> > I want to add following change to fortran-2.eclass to achieve more 
> > simpler usage.
> > 
> > The patch will make the eclass depend on virtual/fortran so that
> > no manual addition is needed. Two exception are present, a) the
> > ebuild has the USE flag fortran, then we check for that, or b) the
> > FORTRAN_OPTIONAL variable is set, which leaves the control to the
> > ebuild (e.g. for cases like "lapack? ( virtual/fortran )").
> > 
> > This is the best coverage of the use cases present, because
> > 
> > * most ebuild using the eclass want to have a fortran compiler *
> > most other trigger optional fortran support through USE=fortran *
> > only minor have different USE for this purpose (e.g. numpy)
> > 
> > Thanks for comments,
> > 
> > Justin
> > 
> 
> You cannot check the value of IUSE in global scope in an eclass, as at
> least portage actually unsets it before sourcing an eclass (also, it
> is not defined in PMS what value IUSE would have at that point).  You
> also got a conditional backwards -- if you don't set FORTRAN_OPTIONAL
> with that patch, then *nothing* gets appended to DEPEND -- if you do
> set it, then DEPEND="virtual/fortran" will always be set (with your
> current logic).

Example: numpy, used by many gtk applications.
fortran is only needed when lapack USE is enabled.

I disabled fortran, an now, I /need/ to have it because the ebuild.

https://bugs.gentoo.org/show_bug.cgi?id=437536

Xavier Miller.

Re: [gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran

[Chí-Thanh Christopher Nguyễn]

justin schrieb:
> Hi,
> 
> I want to add following change to fortran-2.eclass to achieve more 
> simpler usage.
> 
> The patch will make the eclass depend on virtual/fortran so that
> no manual addition is needed. Two exception are present, a) the
> ebuild has the USE flag fortran, then we check for that, or b) the
> FORTRAN_OPTIONAL variable is set, which leaves the control to the
> ebuild (e.g. for cases like "lapack? ( virtual/fortran )").

I suggest that you do something similar to the XORG_DRI variable in
xorg-2.eclass.

For example:
FORTRAN_WANT_COMPILER=no would not add a virtual/fortran dependency
FORTRAN_WANT_COMPILER=always would unconditionally depend on
virtual/fortran
FORTRAN_WANT_COMPILER=useflag would depend on useflag? ( virtual/fortran )

To avoid breaking existing packages, you could default to
FORTRAN_WANT_COMPILER=fortran


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran

[Chí-Thanh Christopher Nguyễn]

Chí-Thanh Christopher Nguyễn schrieb:
> To avoid breaking existing packages, you could default to
> FORTRAN_WANT_COMPILER=fortran

Sorry, it has to be FORTRAN_WANT_COMPILER=always


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran

[justin]

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

On 10/7/12 8:19 PM, Chí-Thanh Christopher Nguyễn wrote:
> justin schrieb:
>> Hi,
>>
>> I want to add following change to fortran-2.eclass to achieve more 
>> simpler usage.
>>
>> The patch will make the eclass depend on virtual/fortran so that
>> no manual addition is needed. Two exception are present, a) the
>> ebuild has the USE flag fortran, then we check for that, or b) the
>> FORTRAN_OPTIONAL variable is set, which leaves the control to the
>> ebuild (e.g. for cases like "lapack? ( virtual/fortran )").
> 
> I suggest that you do something similar to the XORG_DRI variable in
> xorg-2.eclass.
> 
> For example:
> FORTRAN_WANT_COMPILER=no would not add a virtual/fortran dependency
> FORTRAN_WANT_COMPILER=always would unconditionally depend on
> virtual/fortran
> FORTRAN_WANT_COMPILER=useflag would depend on useflag? ( virtual/fortran )
> 
> To avoid breaking existing packages, you could default to
> FORTRAN_WANT_COMPILER=fortran
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 
> 

Thanks for that suggestion. Please find the new version attached. It
basically follows what is done in the xorg-2.eclass. But we allow a list
of USE and don't allow a no, because the eclass itself needs a fortran
compiler.

Thanks,
justin

[-- Attachment #1.2: fortran.patch --]
[-- Type: text/plain, Size: 1027 bytes --]

Index: fortran-2.eclass
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/fortran-2.eclass,v
retrieving revision 1.11
diff -u -B -r1.11 fortran-2.eclass
--- fortran-2.eclass	7 Oct 2012 14:53:43 -0000	1.11
+++ fortran-2.eclass	7 Oct 2012 18:52:49 -0000
@@ -35,6 +35,32 @@
 
 inherit eutils toolchain-funcs
 
+# @ECLASS-VARIABLE: FORTRAN_SUPPORT
+# @DESCRIPTION:
+# If your package has an optional fortran support, set this variable
+# to the space seperated list of USE triggering the fortran
+# dependence.
+#
+# e.g. FORTRAN_SUPPORT=lapack would result in
+#
+# DEPEND="lapack? ( virtual/fortran )"
+#
+# If unset, we always depend on virtual/fortran.
+: ${FORTRAN_SUPPORT:=always}
+
+DEPEND=""
+for _f_use in ${FORTRAN_SUPPORT}; do
+	case ${_f_use} in
+		always)
+			DEPEND+=" virtual/fortran"
+			;;
+		*)
+			DEPEND+=" ${FORTRAN_SUPPORT}? ( virtual/fortran )"
+			;;
+	esac
+done
+RDEPEND="${DEPEND}"
+
 # @FUNCTION: _write_testsuite
 # @INTERNAL
 # @DESCRIPTION:

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

Re: [gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/10/12 02:56 PM, justin wrote:
> On 10/7/12 8:19 PM, Chí-Thanh Christopher Nguyễn wrote:
>> justin schrieb:
>>> Hi,
>>> 
>>> I want to add following change to fortran-2.eclass to achieve
>>> more simpler usage.
>>> 
>>> The patch will make the eclass depend on virtual/fortran so
>>> that no manual addition is needed. Two exception are present,
>>> a) the ebuild has the USE flag fortran, then we check for that,
>>> or b) the FORTRAN_OPTIONAL variable is set, which leaves the
>>> control to the ebuild (e.g. for cases like "lapack? (
>>> virtual/fortran )").
>> 
>> I suggest that you do something similar to the XORG_DRI variable
>> in xorg-2.eclass.
>> 
>> For example: FORTRAN_WANT_COMPILER=no would not add a
>> virtual/fortran dependency FORTRAN_WANT_COMPILER=always would
>> unconditionally depend on virtual/fortran 
>> FORTRAN_WANT_COMPILER=useflag would depend on useflag? (
>> virtual/fortran )
>> 
>> To avoid breaking existing packages, you could default to 
>> FORTRAN_WANT_COMPILER=fortran
>> 
>> 
>> Best regards, Chí-Thanh Christopher Nguyễn
>> 
>> 
> 
> Thanks for that suggestion. Please find the new version attached.
> It basically follows what is done in the xorg-2.eclass. But we
> allow a list of USE and don't allow a no, because the eclass itself
> needs a fortran compiler.
> 
> Thanks, justin


Looks better, but it would still be a good idea to have a possibility
of setting FORTRAN_SUPPORT=no so that the eclass can be used without
setting *DEPEND if a dev so desires.

Right now it looks like FORTRAN_SUPPORT=no would result in
DEPEND+="no? (virtual/fortran)"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlB0IrMACgkQ2ugaI38ACPDCUAEAnMHvFfUv66mawyHc1cY7E6V3
de/3vSIcxPDjNuHLFlMA/Arhg6q0M2E3ECUZI83WYdNkKEQPSoD4uhqbD41X2VoO
=8oKW
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran

[justin]

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

On 09/10/12 15:12, Ian Stakenvicius wrote:
> On 07/10/12 02:56 PM, justin wrote:
>> On 10/7/12 8:19 PM, Chí-Thanh Christopher Nguyễn wrote:
>>> justin schrieb:
>>>> Hi,
>>>>
>>>> I want to add following change to fortran-2.eclass to achieve
>>>> more simpler usage.
>>>>
>>>> The patch will make the eclass depend on virtual/fortran so
>>>> that no manual addition is needed. Two exception are present,
>>>> a) the ebuild has the USE flag fortran, then we check for that,
>>>> or b) the FORTRAN_OPTIONAL variable is set, which leaves the
>>>> control to the ebuild (e.g. for cases like "lapack? (
>>>> virtual/fortran )").
>>>
>>> I suggest that you do something similar to the XORG_DRI variable
>>> in xorg-2.eclass.
>>>
>>> For example: FORTRAN_WANT_COMPILER=no would not add a
>>> virtual/fortran dependency FORTRAN_WANT_COMPILER=always would
>>> unconditionally depend on virtual/fortran 
>>> FORTRAN_WANT_COMPILER=useflag would depend on useflag? (
>>> virtual/fortran )
>>>
>>> To avoid breaking existing packages, you could default to 
>>> FORTRAN_WANT_COMPILER=fortran
>>>
>>>
>>> Best regards, Chí-Thanh Christopher Nguyễn
>>>
>>>
> 
>> Thanks for that suggestion. Please find the new version attached.
>> It basically follows what is done in the xorg-2.eclass. But we
>> allow a list of USE and don't allow a no, because the eclass itself
>> needs a fortran compiler.
> 
>> Thanks, justin
> 
> 
> Looks better, but it would still be a good idea to have a possibility
> of setting FORTRAN_SUPPORT=no so that the eclass can be used without
> setting *DEPEND if a dev so desires.
> 
> Right now it looks like FORTRAN_SUPPORT=no would result in
> DEPEND+="no? (virtual/fortran)"
> 

I thought about it, but it makes no sense. There is exactly no need for
an ebuild to use this eclass if no fortran support is required.
The only purpose of this eclass is to check that F77 and FC are valid
fortran compilers.
But in order to have this possibility available I will add it.

Thanks for commenting,
Jusitn


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

Re: [gentoo-dev] Re: RFC: fortran-2.eclass to depend on virtual/fortran

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 631 bytes --]

On Sunday 07 October 2012 13:58:04 justin wrote:
> On 10/7/12 7:36 PM, Jonathan Callen wrote:
> > You cannot check the value of IUSE in global scope in an eclass, as at
> > least portage actually unsets it before sourcing an eclass (also, it
> > is not defined in PMS what value IUSE would have at that point).
> 
> Regarding your first point I copied the behavior from the
> toolchain.eclass and I thought it would work. Testing it, I see you are
> right. Any suggestion how to check for a USE being IUSE in an eclass?

toolchain.eclass is testing its own IUSE which is why it works, not the IUSE 
from ebuilds
-mike

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

Re: [gentoo-dev] Re: RFC: fortran-2.eclass to depend on virtual/fortran

[Justin]

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

On 09.10.2012 23:19, Mike Frysinger wrote:
> On Sunday 07 October 2012 13:58:04 justin wrote:
>> On 10/7/12 7:36 PM, Jonathan Callen wrote:
>>> You cannot check the value of IUSE in global scope in an eclass, as at
>>> least portage actually unsets it before sourcing an eclass (also, it
>>> is not defined in PMS what value IUSE would have at that point).
>>
>> Regarding your first point I copied the behavior from the
>> toolchain.eclass and I thought it would work. Testing it, I see you are
>> right. Any suggestion how to check for a USE being IUSE in an eclass?
> 
> toolchain.eclass is testing its own IUSE which is why it works, not the IUSE 
> from ebuilds
> -mike
> 

Right I just saw this.
Thanks,
Justin


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