Summary: | Request for calling intltoolize in eautoreconf when appropriate | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mart Raudsepp <leio> |
Component: | Eclasses | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gnome, maksbotan |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 199595, 211298, 416789 | ||
Attachments: | gnome-autogen.sh from gnome-common-2.20.0 for reference |
Description
Mart Raudsepp
2008-02-24 16:51:16 UTC
Apparently it's about mismatch between aclocal.m4 and Makefile.in.in instead.. Information and reasoning from upstream, discussed long ago - slightly edited IRC log: <leio> we have everything released with intltool-0.35.x fail build if the intltool installed on the system is 0.36.2 <dobey> you're probably running autoreconf, and not intltoolize <dobey> so you are mismatching the m4 and intltool scripts and Makefile.in.in <leio> yup, @INTLTOOL_MERGE comes up in the error message <dobey> because packages that use intltool, include the intltool scripts in their tarballs currently <dobey> yes you need to re-run intltoolize if you're going to do autoreconf <dobey> autoreconf has no knowledge of intltool <leio> hmm, I suppose intltoolize -f was supposed to come after autoreconf ;) <leio> and I don't believe we are using autoreconf anyway. We have our own eautoreconf <leio> that runs aclocal, automake, autoconf and a couple other things. But yes, that seems to be the problem <dobey> well whatever. the problem is you need to run intltoolize :) <leio> with --force ? <dobey> -f -c probably <leio> hmm, up to now lack of -c hasn't been a problem for some reason <dobey> oh maybe it unlinks first then <leio> what's the best way to find out if a package is using intltoolize? To have the best way to improve our eautoreconf to automatically intltoolize -f, but only on those packages that do use intltool <dobey> grep "^(IT|AC)_PROG_INTLTOOL" configure.{in,ac} <dobey> see gnome-autogen.sh from gnome-common or a more comprehensive check ... <dobey> i was hoping to get a few more patches in, and then making a final 0.36.x release <dobey> because i really want to get it out, and start doing the work on 0.40, to get rid of the need to have intltool included in tarballs .... <leio> would it be a good idea to try to push intltoolize into our eautoreconf? <dobey> yes <leio> with intltoolized project detection <leio> I mean in relation to the planned 0.40 work with not needing tarballs to carry the files <dobey> if intltoolize is what copies the Makefile.in.in over, then yes, it will still need to be run <leio> one problem is that maintainer are stuck at ancient versions often <leio> well, I don't know if it will be, but I suppose nothing else can be ;p <dobey> yeah, i'm not sure <leio> so with 0.40 it's not sure if it'll be necessary or not? <dobey> i'm not 100% certain right now, no <leio> I mean, if I go push that into eautoreconf, then later backing it out for 0.40 cases is not so good <dobey> the Makefile.in.in copying is the big thing <dobey> well <dobey> you won't have to back it out <leio> it'll be pretty much a no-op then? <dobey> the script will be around for a while no matter what, for compatibility reasons <dobey> if it just does nothing, it will just be #!/bin/true <dobey> so that it won't break stuff :) Created attachment 144521 [details]
gnome-autogen.sh from gnome-common-2.20.0 for reference
here's the autogen from gnome-common for reference. case-insensitive search for intltool for relevant parts, especially around $INTLTOOLIZE
I'm retracting my request for now. It seems upgrade path is more or less fine, and upstream might remove this kind of Makefile inconsistency possibility in a future 0.40 release, so there's time to think about it more depending on what way upstream goes. *** Bug 327673 has been marked as a duplicate of this bug. *** this ended up getting fast tracked after merging autopoint support http://sources.gentoo.org/eclass/autotools.eclass?r1=1.139&r2=1.140 |