RFC: fortran-2.eclass to depend on virtual/fortran

10-07-2012, 05:20 PM

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

10-07-2012, 05:36 PM

-----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
GapkNJRpBjiihYZ1n5pAtBpUvbKqgAo4zvvXX2AvLDfUazcpnP h3ZdW8Gc8JtycF
cvCrUoUfV+0MY29DEcvL0tV5wX9ha5B5YEurR/zoPQ29V6eJqho21G+GZJ6L4Mdj
rIcTRDf4izaDqiunRDRQp51udYEnAQLR8I9FAA4ybh1Dd536xm nm3jdDkGtpvgrW
15vWMdr8ETkmy5eK59K/iP6U4IzPldBXff+rKyIlss/D6CNrXI0WqeYY2PdFUHGk
E+C4Sqx633AjevfS04c+6feAcsS3gIpZWVuzA0BZSXeFUFB7Cd ph1RwHpLOYM50Q
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-----

10-07-2012, 05:58 PM

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

10-07-2012, 06:01 PM

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

10-07-2012, 06:12 PM

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.

10-07-2012, 06:56 PM

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

10-09-2012, 01:12 PM

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

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

10-09-2012, 01:19 PM

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

10-09-2012, 09:19 PM

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

10-10-2012, 05:04 AM

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