Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Wednesday 13 February 2008 20:30:30 Petteri Räty wrote: How can I use PATCHES without quoting issues? Attached is a patch that fixes this. So is someone going to fix epatch too? Otherwise it is rather moot. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On 13-02-2008 08:50:19 +0100, Rémi Cardona wrote: Petteri Räty a écrit : What do you think about adding support to base.eclass for running eautoreconf? In most of the ebuilds where we need to run eautoreconf, we usually apply patches. I can't remember of an ebuild where we just run eautoreconf on its own. +1 If you need to run eautoreconf without adding patches, it may be worth adding a comment explaining why. In the end, that won't help us at all (which is no reason not to have this :) ) but I'm afraid that adding options for semi-hidden stuff can come and bite us later, as we add more and more of those. I think it should not be added as it hides something quite important. - it takes a lot of time on most platforms I run - it may break (especially during bootstrapping, eautoreconfs are hell) - it may introduce extra deps/caution (e.g. gettext macros being available) So I'd prefer to keep it quite clear that this is happening, instead of hiding it somewhere in an obscure corner of the ebuild. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
Fabian Groffen kirjoitti: On 13-02-2008 08:50:19 +0100, Rémi Cardona wrote: Petteri Räty a écrit : What do you think about adding support to base.eclass for running eautoreconf? In most of the ebuilds where we need to run eautoreconf, we usually apply patches. I can't remember of an ebuild where we just run eautoreconf on its own. +1 If you need to run eautoreconf without adding patches, it may be worth adding a comment explaining why. base.eclass supports the PATCHES variable which is why I use it in the first place Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
Fabian Groffen kirjoitti: I think it should not be added as it hides something quite important. - it takes a lot of time on most platforms I run - it may break (especially during bootstrapping, eautoreconfs are hell) - it may introduce extra deps/caution (e.g. gettext macros being available) So I'd prefer to keep it quite clear that this is happening, instead of hiding it somewhere in an obscure corner of the ebuild. I didn't propose always running it. I don't think spotting EAUTORECONF is any harder than eautoreconf. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Mittwoch, 13. Februar 2008, Petteri Räty wrote:
Fabian Groffen kirjoitti:
On 13-02-2008 08:50:19 +0100, Rémi Cardona wrote:
Petteri Räty a écrit :
What do you think about adding support to base.eclass for running
eautoreconf?
In most of the ebuilds where we need to run eautoreconf, we usually
apply patches. I can't remember of an ebuild where we just run
eautoreconf on its own.
+1
If you need to run eautoreconf without adding patches, it may be worth
adding a comment explaining why.
base.eclass supports the PATCHES variable which is why I use it in the
first place
How can I use PATCHESwithout quoting issues?
default is this (when not using relative pathes):
PATCHES=${FILESDIR}/p1.diff ${FILESDIR}/p2.diff
Regards
Matthias
--
Matthias Schwarzott (zzam)
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Wed, 13 Feb 2008 01:44:22 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
What do you think about adding support to base.eclass for running
eautoreconf?
so instead of
src_unpack() {
unpack ${A}
cd ${A}
eautoreconf
}
would just add
EAUTORECONF=yes
inherit base
Regards,
Petteri
And if you can't run eautoreconf but instead one of specific commands,
eautoconf, eautomake..
Or what if you need to run AT_M4DIR=/path/to/macros eautoreconf?
Or when you are about to remove eautoreconf, spot that fbsd is
keyworded and need to substitute it with elibtoolize to avoid
.so version breakage wouldn't it be easier to convert from what
we use now?
What about WANT_ variables?
-drac
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
Alec Warner kirjoitti: The former is much clearer...I don't see the gain... also in the former example you neglected to inherit autotools ;) That would happen conditionally in base.eclass Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
В Срд, 13/02/2008 в 13:22 +0100, Matthias Schwarzott пишет:
How can I use PATCHES without quoting issues?
default is this (when not using relative pathes):
PATCHES=${FILESDIR}/p1.diff ${FILESDIR}/p2.diff
You can not. This should be fixed like we did for font.eclass (bug
201834). BTW, kernel.eclass and I think some others have this problem
too.
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Wed, 13 Feb 2008 01:44:22 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
What do you think about adding support to base.eclass for running
eautoreconf?
so instead of
src_unpack() {
unpack ${A}
cd ${A}
eautoreconf
}
would just add
EAUTORECONF=yes
inherit base
How many packages do you think could directly benefit from this?
Marius
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
Matthias Schwarzott kirjoitti:
How can I use PATCHESwithout quoting issues?
Attached is a patch that fixes this.
Regards,
Petteri
Index: base.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/base.eclass,v
retrieving revision 1.32
diff -u -r1.32 base.eclass
--- base.eclass 12 Feb 2008 23:51:51 - 1.32
+++ base.eclass 13 Feb 2008 19:29:21 -
@@ -34,10 +34,21 @@
debug-print-section autopatch
debug-print $FUNCNAME: autopatch: PATCHES=$PATCHES,
PATCHES1=$PATCHES1
cd ${S}
- for x in $PATCHES $PATCHES1; do
- debug-print $FUNCNAME: autopatch: patching
from ${x}
- epatch ${x}
- done
+ if [[ [EMAIL PROTECTED] -gt 1 ]]; then
+ for x in [EMAIL PROTECTED]; do
+ debug-print $FUNCNAME: autopatch:
patching from ${x}
+ epatch ${x}
+ done
+ else
+ if [[ ${PATCHES} =~ [[:space:]] ]]; then
+ eqawarn ${CATEGORY}/${P} should be
updated to use arrays
+ eqawarn for \${PATCHES}, report this
to http://bugs.gentoo.org;
+ fi
+ for x in ${PATCHES} ${PATCHES1}; do
+ debug-print $FUNCNAME: autopatch:
patching from ${x}
+ epatch ${x}
+ done
+ fi
;;
all)
debug-print-section all
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
Samuli Suominen kirjoitti: And if you can't run eautoreconf but instead one of specific commands, eautoconf, eautomake.. Or what if you need to run AT_M4DIR=/path/to/macros eautoreconf? Or when you are about to remove eautoreconf, spot that fbsd is keyworded and need to substitute it with elibtoolize to avoid .so version breakage wouldn't it be easier to convert from what we use now? What about WANT_ variables? -drac WANT_ variables work work as before. For the other cases just use a custom src_unpack function like before. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
Petteri Räty wrote: Attached is a patch that fixes this. Arrays? How non-POSIX1 Anyway, why don't we instead discuss what phases to add to next EAPI, so we can avoid these hacks :) -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Feb 13, 2008 10:44 AM, Petteri Räty [EMAIL PROTECTED] wrote:
What do you think about adding support to base.eclass for running
eautoreconf?
so instead of
src_unpack() {
unpack ${A}
cd ${A}
eautoreconf
}
would just add
EAUTORECONF=yes
inherit base
Sounds sensible
Paul
[gentoo-dev] RFC: adding support for running eautoconf to base.eclass
What do you think about adding support to base.eclass for running
eautoreconf?
so instead of
src_unpack() {
unpack ${A}
cd ${A}
eautoreconf
}
would just add
EAUTORECONF=yes
inherit base
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Wed, 13 Feb 2008 01:44:22 +0200 Petteri Räty [EMAIL PROTECTED] wrote: What do you think about adding support to base.eclass for running eautoreconf? Isn't base.eclass considered pretty much dead and to be avoided? It's a throwback to how eclasses were originally going to work, and it doesn't correspond nicely to ebuild default functions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On 2/12/08, Petteri Räty [EMAIL PROTECTED] wrote:
What do you think about adding support to base.eclass for running
eautoreconf?
so instead of
src_unpack() {
unpack ${A}
cd ${A}
eautoreconf
}
would just add
EAUTORECONF=yes
inherit base
The former is much clearer...I don't see the gain... also in the
former example you neglected to inherit autotools ;)
Regards,
Petteri
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
Petteri Räty a écrit : What do you think about adding support to base.eclass for running eautoreconf? *puts on Gnome hat* In most of the ebuilds where we need to run eautoreconf, we usually apply patches. I can't remember of an ebuild where we just run eautoreconf on its own. In the end, that won't help us at all (which is no reason not to have this :) ) but I'm afraid that adding options for semi-hidden stuff can come and bite us later, as we add more and more of those. Cheers, Rémi -- gentoo-dev@lists.gentoo.org mailing list
