FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 10-07-2012, 05:20 PM
justin
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

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:
 
Old 10-07-2012, 05:36 PM
Jonathan Callen
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

-----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-----
 
Old 10-07-2012, 05:58 PM
justin
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

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
 
Old 10-07-2012, 06:01 PM
Ciaran McCreesh
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

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
 
Old 10-07-2012, 06:12 PM
Xavier Miller
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

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.
 
Old 10-07-2012, 06:56 PM
justin
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

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:
 
Old 10-09-2012, 01:12 PM
Ian Stakenvicius
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

-----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-----
 
Old 10-09-2012, 01:19 PM
justin
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

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
 
Old 10-09-2012, 09:19 PM
Mike Frysinger
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

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
 
Old 10-10-2012, 05:04 AM
Justin
 
Default RFC: fortran-2.eclass to depend on virtual/fortran

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
 

Thread Tools




All times are GMT. The time now is 07:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org