1 |
On Monday 21 May 2012 12:08:21 Alexandre Rostovtsev wrote: |
2 |
> On Mon, 2012-05-21 at 11:36 -0400, Mike Frysinger wrote: |
3 |
> > On Monday 21 May 2012 02:41:18 Alexandre Rostovtsev wrote: |
4 |
> > > On Sun, 2012-05-20 at 06:32 -0400, Mike Frysinger wrote: |
5 |
> > > > i've extended eautoreconf to automatically call autopoint when the |
6 |
> > > > package uses gettext. the configure check might seem naïve, but this |
7 |
> > > > is how autoreconf itself does it. this hopefully shouldn't break |
8 |
> > > > any packages (at least, none that weren't already broken), but if |
9 |
> > > > you guys start seeing eautoreconf failures where there were none |
10 |
> > > > before, feel free to cc base-system. -mike |
11 |
> > > > |
12 |
> > > > --- autotools.eclass |
13 |
> > > > +++ autotools.eclass |
14 |
> > > > @@ -162,6 +162,9 @@ eautoreconf() { |
15 |
> > > > |
16 |
> > > > einfo "Running eautoreconf in '${PWD}' ..." |
17 |
> > > > [[ -n ${auxdir}${macdir} ]] && mkdir -p ${auxdir} ${macdir} |
18 |
> > > > eaclocal |
19 |
> > > > |
20 |
> > > > + if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? ; then |
21 |
> > > > + eautopoint --force |
22 |
> > > > + fi |
23 |
> > > > |
24 |
> > > > [[ ${CHOST} == *-darwin* ]] && g=g |
25 |
> > > > if ${LIBTOOLIZE:-${g}libtoolize} -n --install >& /dev/null ;then |
26 |
> > > > |
27 |
> > > > _elibtoolize --copy --force --install |
28 |
> > > |
29 |
> > > This change broke many gnome-related packages, see bug #416789. You |
30 |
> > > cannot assume that every package that uses AM_GNU_GETTEXT_VERSION wants |
31 |
> > > (just) autopoint; |
32 |
> > |
33 |
> > two things: |
34 |
> > - eautoreconf acts like autoreconf which means it can assume that use of |
35 |
> > AM_GNU_GETTEXT_VERSION implies use of `autopoint` |
36 |
> > - it doesn't assume *just* autopoint -- nothing is stopping you from |
37 |
> > running any other random tools you like (such as intltool) |
38 |
> |
39 |
> Changing eautoreconf's behavior to exactly match vanilla autoconf may |
40 |
> make sense from your point of view as an autotools maintainer, but it |
41 |
> breaks ebuilds that do not want vanilla autoconf semantics and that are |
42 |
> relying on eautoreconf's old, intltool-friendly behavior. |
43 |
|
44 |
it still makes sense. i don't have a problem integrating a call to intltool, |
45 |
but your proposed code isn't the way to go. |
46 |
|
47 |
> > > there are also packages that use intltool (to be run |
48 |
> > > after autopoint) or glib-gettext (in which case autopoint should not be |
49 |
> > > used at all). |
50 |
> > |
51 |
> > so attempting to run `autoreconf` in those packages fails ? |
52 |
> |
53 |
> It results in configure failure. E.g. |
54 |
|
55 |
so the answer is "yes, these packages fail to work with `autoreconf`" |
56 |
|
57 |
> > > +# @ECLASS-VARIABLE: WANT_INTLTOOL |
58 |
> > > +# @DESCRIPTION: |
59 |
> > > +# Do you want intltool? Valid values here are "latest" and "none". |
60 |
> > > +: ${WANT_INTLTOOL:=latest} |
61 |
> > > ... |
62 |
> > > +_intltool_atom="dev-util/intltool" |
63 |
> > > +if [[ -n ${WANT_INTLTOOL} ]] ; then |
64 |
> > > + case ${WANT_INTLTOOL} in |
65 |
> > > + none) _intltool_atom="" ;; |
66 |
> > > + latest) ;; |
67 |
> > > + *) die "Invalid WANT_INTLTOOL value '${WANT_INTLTOOL}'" ;; |
68 |
> > > + esac |
69 |
> > > + export WANT_LIBTOOL |
70 |
> > > +fi |
71 |
> > > ... |
72 |
> > > -AUTOTOOLS_DEPEND="${_automake_atom} ${_autoconf_atom} ${_libtool_atom}" |
73 |
> > > +AUTOTOOLS_DEPEND="${_automake_atom} ${_autoconf_atom} ${_intltool_atom} |
74 |
> > |
75 |
> > no. this adds intltool as a dependency to every package inherting this |
76 |
> > eclass. |
77 |
> |
78 |
> Why is that unacceptable? |
79 |
|
80 |
fairly obvious why |
81 |
|
82 |
> Realistically, every Gentoo machine, with the exception of pure deployment |
83 |
> installations that don't build any packages (and therefore don't care about |
84 |
> autotools.eclass anyway), already has intltool installed. |
85 |
|
86 |
extending the set of machines that you care about to include all setups is |
87 |
obviously wrong (i certainly have machines that "build packages" that don't |
88 |
have intltool installed). and even if that wasn't true, it'd be entirely |
89 |
irrelevant. spurious dependencies are not acceptable. |
90 |
-mike |