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 03-05-2010, 05:59 PM
Mike Frysinger
 
Default making autotools.eclass depends flexible

sometimes i have optional patches (ignoring the "patches should always be
applied") where autotools should be run. always inheriting autotools is
currently annoying because it always adds the related dependencies. USE based
inherits are obviously out.

so unless there's some burgeoning standard i'm not aware of, below is what i
have in mind. packages set AUTOTOOLS_AUTO_DEPEND to "no" before inheriting
autotools.eclass and that allows them to put ${AUTOTOOLS_DEPEND} behind a USE
flag in their own DEPEND string.

--- autotools.eclass 8 Feb 2010 11:04:01 -0000 1.92
+++ autotools.eclass 5 Mar 2010 18:09:54 -0000
@@ -46,10 +46,20 @@ if [[ -n ${WANT_AUTOCONF} ]] ; then
esac
export WANT_AUTOCONF
fi
-DEPEND="${_automake_atom}
- ${_autoconf_atom}"
-[[ ${CATEGORY}/${PN} != "sys-devel/libtool" ]] && DEPEND="${DEPEND} >=sys-devel/libtool-2.2.6b"
+
+AUTOTOOLS_DEPEND="${_automake_atom} ${_autoconf_atom}"
+[[ ${CATEGORY}/${PN} != "sys-devel/libtool" ]] && AUTOTOOLS_DEPEND="${AUTOTOOLS_DEPEND}
>=sys-devel/libtool-2.2.6b"
RDEPEND=""
+
+# @ECLASS-VARIABLE: AUTOTOOLS_AUTO_DEPEND
+# @DESCRIPTION:
+# Set to 'no' to disable automatically adding to DEPEND. This lets
+# ebuilds former conditional depends by using ${AUTOTOOLS_DEPEND} in
+# their own DEPEND string.
+if [[ ${AUTOTOOLS_AUTO_DEPEND} != "no" ]] ; then
+ DEPEND=${AUTOTOOLS_AUTO_DEPEND}
+fi
+
unset _automake_atom _autoconf_atom

# @ECLASS-VARIABLE: AM_OPTS
-mike
 
Old 03-06-2010, 06:11 AM
Petteri Räty
 
Default making autotools.eclass depends flexible

On 03/05/2010 08:59 PM, Mike Frysinger wrote:
> sometimes i have optional patches (ignoring the "patches should always be
> applied") where autotools should be run. always inheriting autotools is
> currently annoying because it always adds the related dependencies. USE based
> inherits are obviously out.
>
> so unless there's some burgeoning standard i'm not aware of, below is what i
> have in mind. packages set AUTOTOOLS_AUTO_DEPEND to "no" before inheriting
> autotools.eclass and that allows them to put ${AUTOTOOLS_DEPEND} behind a USE
> flag in their own DEPEND string.
>

What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
DEPENDs should be under. This approach doesn't allow the ebuild
maintainer to forget adding the depends.

Regards,
Petteri
 
Old 03-06-2010, 05:28 PM
Jonathan Callen
 
Default making autotools.eclass depends flexible

On 03/06/2010 02:11 AM, Petteri Räty wrote:
> What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
> DEPENDs should be under. This approach doesn't allow the ebuild
> maintainer to forget adding the depends.

That approach also disallows (or makes unduly difficult) making the
dependency such that "I need autotools on USE=kernel_SunOS or
USE=kernel_freemint, but nowhere else" or "I need autotools when USE=foo
and USE=bar, but not otherwise".

--
Jonathan Callen
 
Old 03-06-2010, 05:45 PM
Petteri Räty
 
Default making autotools.eclass depends flexible

On 03/06/2010 08:28 PM, Jonathan Callen wrote:
> On 03/06/2010 02:11 AM, Petteri Räty wrote:
>> What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
>> DEPENDs should be under. This approach doesn't allow the ebuild
>> maintainer to forget adding the depends.
>
> That approach also disallows (or makes unduly difficult) making the
> dependency such that "I need autotools on USE=kernel_SunOS or
> USE=kernel_freemint, but nowhere else" or "I need autotools when USE=foo
> and USE=bar, but not otherwise".
>

You can provide both approaches if there ever is a need for things you
said but in my opinion just declaring the use flag should be the
preferred approach as it results in less code in the individual ebuilds.

Regards,
Petteri
 
Old 03-07-2010, 04:42 PM
Mike Frysinger
 
Default making autotools.eclass depends flexible

On Saturday 06 March 2010 02:11:15 Petteri Räty wrote:
> On 03/05/2010 08:59 PM, Mike Frysinger wrote:
> > sometimes i have optional patches (ignoring the "patches should always be
> > applied") where autotools should be run. always inheriting autotools is
> > currently annoying because it always adds the related dependencies. USE
> > based inherits are obviously out.
> >
> > so unless there's some burgeoning standard i'm not aware of, below is
> > what i have in mind. packages set AUTOTOOLS_AUTO_DEPEND to "no" before
> > inheriting autotools.eclass and that allows them to put
> > ${AUTOTOOLS_DEPEND} behind a USE flag in their own DEPEND string.
>
> What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
> DEPENDs should be under. This approach doesn't allow the ebuild
> maintainer to forget adding the depends.

i'm more inclined towards Jonathan's opinion, so ive kept the proposed
behavior (plus a fix from Torsten).
-mike
 
Old 03-07-2010, 05:31 PM
Petteri Räty
 
Default making autotools.eclass depends flexible

On 03/07/2010 07:42 PM, Mike Frysinger wrote:
> On Saturday 06 March 2010 02:11:15 Petteri Räty wrote:
>> On 03/05/2010 08:59 PM, Mike Frysinger wrote:
>>> sometimes i have optional patches (ignoring the "patches should always be
>>> applied") where autotools should be run. always inheriting autotools is
>>> currently annoying because it always adds the related dependencies. USE
>>> based inherits are obviously out.
>>>
>>> so unless there's some burgeoning standard i'm not aware of, below is
>>> what i have in mind. packages set AUTOTOOLS_AUTO_DEPEND to "no" before
>>> inheriting autotools.eclass and that allows them to put
>>> ${AUTOTOOLS_DEPEND} behind a USE flag in their own DEPEND string.
>>
>> What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
>> DEPENDs should be under. This approach doesn't allow the ebuild
>> maintainer to forget adding the depends.
>
> i'm more inclined towards Jonathan's opinion, so ive kept the proposed
> behavior (plus a fix from Torsten).
> -mike

And what about my latest response to him?

Regards,
Petteri
 
Old 03-07-2010, 05:36 PM
Mike Frysinger
 
Default making autotools.eclass depends flexible

On Sunday 07 March 2010 13:31:56 Petteri Räty wrote:
> On 03/07/2010 07:42 PM, Mike Frysinger wrote:
> > On Saturday 06 March 2010 02:11:15 Petteri Räty wrote:
> >> On 03/05/2010 08:59 PM, Mike Frysinger wrote:
> >>> sometimes i have optional patches (ignoring the "patches should always
> >>> be applied") where autotools should be run. always inheriting
> >>> autotools is currently annoying because it always adds the related
> >>> dependencies. USE based inherits are obviously out.
> >>>
> >>> so unless there's some burgeoning standard i'm not aware of, below is
> >>> what i have in mind. packages set AUTOTOOLS_AUTO_DEPEND to "no" before
> >>> inheriting autotools.eclass and that allows them to put
> >>> ${AUTOTOOLS_DEPEND} behind a USE flag in their own DEPEND string.
> >>
> >> What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
> >> DEPENDs should be under. This approach doesn't allow the ebuild
> >> maintainer to forget adding the depends.
> >
> > i'm more inclined towards Jonathan's opinion, so ive kept the proposed
> > behavior (plus a fix from Torsten).
>
> And what about my latest response to him?

considering your proposal saves ${FOO} in DEPEND, it hasnt changed my opinion
-mike
 
Old 03-07-2010, 06:08 PM
Petteri Räty
 
Default making autotools.eclass depends flexible

On 03/07/2010 08:36 PM, Mike Frysinger wrote:
> On Sunday 07 March 2010 13:31:56 Petteri Räty wrote:
>> On 03/07/2010 07:42 PM, Mike Frysinger wrote:
>>> On Saturday 06 March 2010 02:11:15 Petteri Räty wrote:
>>>> On 03/05/2010 08:59 PM, Mike Frysinger wrote:
>>>>> sometimes i have optional patches (ignoring the "patches should always
>>>>> be applied") where autotools should be run. always inheriting
>>>>> autotools is currently annoying because it always adds the related
>>>>> dependencies. USE based inherits are obviously out.
>>>>>
>>>>> so unless there's some burgeoning standard i'm not aware of, below is
>>>>> what i have in mind. packages set AUTOTOOLS_AUTO_DEPEND to "no" before
>>>>> inheriting autotools.eclass and that allows them to put
>>>>> ${AUTOTOOLS_DEPEND} behind a USE flag in their own DEPEND string.
>>>>
>>>> What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
>>>> DEPENDs should be under. This approach doesn't allow the ebuild
>>>> maintainer to forget adding the depends.
>>>
>>> i'm more inclined towards Jonathan's opinion, so ive kept the proposed
>>> behavior (plus a fix from Torsten).
>>
>> And what about my latest response to him?
>
> considering your proposal saves ${FOO} in DEPEND, it hasnt changed my opinion
> -mike

Why would it be better to require ebuild writers to have do it
themselves instead of the eclass automatically taking care of it?

Regards,
Petteri
 
Old 03-07-2010, 08:44 PM
Mike Frysinger
 
Default making autotools.eclass depends flexible

On Sunday 07 March 2010 14:08:29 Petteri Räty wrote:
> On 03/07/2010 08:36 PM, Mike Frysinger wrote:
> > On Sunday 07 March 2010 13:31:56 Petteri Räty wrote:
> >> On 03/07/2010 07:42 PM, Mike Frysinger wrote:
> >>> On Saturday 06 March 2010 02:11:15 Petteri Räty wrote:
> >>>> On 03/05/2010 08:59 PM, Mike Frysinger wrote:
> >>>>> sometimes i have optional patches (ignoring the "patches should
> >>>>> always be applied") where autotools should be run. always
> >>>>> inheriting autotools is currently annoying because it always adds
> >>>>> the related dependencies. USE based inherits are obviously out.
> >>>>>
> >>>>> so unless there's some burgeoning standard i'm not aware of, below is
> >>>>> what i have in mind. packages set AUTOTOOLS_AUTO_DEPEND to "no"
> >>>>> before inheriting autotools.eclass and that allows them to put
> >>>>> ${AUTOTOOLS_DEPEND} behind a USE flag in their own DEPEND string.
> >>>>
> >>>> What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
> >>>> DEPENDs should be under. This approach doesn't allow the ebuild
> >>>> maintainer to forget adding the depends.
> >>>
> >>> i'm more inclined towards Jonathan's opinion, so ive kept the proposed
> >>> behavior (plus a fix from Torsten).
> >>
> >> And what about my latest response to him?
> >
> > considering your proposal saves ${FOO} in DEPEND, it hasnt changed my
> > opinion
>
> Why would it be better to require ebuild writers to have do it
> themselves instead of the eclass automatically taking care of it?

as Jonathan mentioned, it gives explicit control via multiple USE flags which
your way does not
-mike
 
Old 03-08-2010, 04:37 AM
Petteri Räty
 
Default making autotools.eclass depends flexible

On 03/07/2010 11:44 PM, Mike Frysinger wrote:
> On Sunday 07 March 2010 14:08:29 Petteri Räty wrote:
>> On 03/07/2010 08:36 PM, Mike Frysinger wrote:
>>> On Sunday 07 March 2010 13:31:56 Petteri Räty wrote:
>>>> On 03/07/2010 07:42 PM, Mike Frysinger wrote:
>>>>> On Saturday 06 March 2010 02:11:15 Petteri Räty wrote:
>>>>>> On 03/05/2010 08:59 PM, Mike Frysinger wrote:
>>>>>>> sometimes i have optional patches (ignoring the "patches should
>>>>>>> always be applied") where autotools should be run. always
>>>>>>> inheriting autotools is currently annoying because it always adds
>>>>>>> the related dependencies. USE based inherits are obviously out.
>>>>>>>
>>>>>>> so unless there's some burgeoning standard i'm not aware of, below is
>>>>>>> what i have in mind. packages set AUTOTOOLS_AUTO_DEPEND to "no"
>>>>>>> before inheriting autotools.eclass and that allows them to put
>>>>>>> ${AUTOTOOLS_DEPEND} behind a USE flag in their own DEPEND string.
>>>>>>
>>>>>> What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
>>>>>> DEPENDs should be under. This approach doesn't allow the ebuild
>>>>>> maintainer to forget adding the depends.
>>>>>
>>>>> i'm more inclined towards Jonathan's opinion, so ive kept the proposed
>>>>> behavior (plus a fix from Torsten).
>>>>
>>>> And what about my latest response to him?
>>>
>>> considering your proposal saves ${FOO} in DEPEND, it hasnt changed my
>>> opinion
>>
>> Why would it be better to require ebuild writers to have do it
>> themselves instead of the eclass automatically taking care of it?
>
> as Jonathan mentioned, it gives explicit control via multiple USE flags which
> your way does not
> -mike

I already said both can be implemented.

Regards,
Petteri
 

Thread Tools




All times are GMT. The time now is 10:03 AM.

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