This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/rfc] Enable PO files.
- From: Andrew Cagney <cagney at gnu dot org>
- To: tromey at redhat dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 06 Aug 2004 12:06:44 -0400
- Subject: Re: [patch/rfc] Enable PO files.
- References: <41091DEB.9020904@gnu.org> <87isc575ry.fsf@fleche.redhat.com>
"Andrew" == Andrew Cagney <cagney@gnu.org> writes:
Andrew> - the output is put in the _build_ directory (instead of RO srcdir)
The only issue with this, I think, is how releases are made -- but I
see from the patch that you already dealt with this.
Andrew> - insisted on using ../intl/
Andrew> I didn't borrow that - GDB will still use an installed intl/ (I'm
Andrew> wondering if its time to boot intl/ out of GDB's distro).
Hmm, I thought the point of doing this is that the stuff in intl,
while readily available on Linux boxes, isn't so available elsewhere.
I could be behind the times, though, I haven't looked at the nuts and
bolts of gettext building in years.
Leading into 6.2, GDB found its self in a situtation where:
- intl/ wasn't needed
- on non-GNU systems, intl/ typically broke the build (serious)
yet we shipped it, doh! Given this, the consequence of enabling i18n
can be illustrated with the table:
GDB: <=6.2 6.3
GNU - i18n
non - -
(On non-GNU systems, unless we put effort into maining our local
src/intl/, it will continue to break and hence will continue to be
--disable-nls'ed).
Lets instead do what we should have done long ago, rely on the installed
intl/. We then:
- fix our intl/ build problem
- remove the burden of [pretending to] maintain intl/
- support i18n where it really matters -> GNU systems
- support i18n on non-GNU systems where intl/'s installed
Andrew> + find * \
Andrew> + -name '*-stub.c' -prune -o \
Andrew> + -name 'testsuite' -prune -o \
Andrew> + -name 'init.c' -prune -o \
Andrew> + -name '*.[hc]' -print
I never liked using find for things like this, since I tend to push
files out of the way by "mv foo.c hacked-foo.c", but I can understand
why you'd do it this way. I suppose it could only negatively affect
some subset of "real gdb developers" anyway, provided releases are
always done from a pristine checkout.
Yes, true.
Andrew