[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS & Gettext
From: |
Akim Demaille |
Subject: |
Re: CVS & Gettext |
Date: |
18 Apr 2002 15:44:18 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) |
| Akim Demaille writes:
| > | > cat >configure.ac <<EOF
| > | > AC_INIT(Foo, 1.0)
| > | > AM_INIT_AUTOMAKE([foreign])
| > | > AM_GNU_GETTEXT
| > | > AC_CONFIG_FILES(Makefile)
| > if $I_want_to_use_gettext; then
| > | > AC_CONFIG_FILES(intl/Makefile po/Makefile.in)
| > fi
| > | > AC_OUTPUT
| > | > EOF
| >
| > and have the proper thing happen.
| >
| > In other words, you just cannot, and should not consider that the
| > presence of an AC_CONFIG_FILES means the presence of a directory.
|
| Right. It is for this reason that gettextize determines whether intl
| is present by looking at the directory structure, not by looking at
| the contents of configure.in/ac.
Actually, I believe that I have demonstrated that Gettextize should
not try to change an existing AC_CONFIG_FILES. Rather, I'd suggest
that it stick a new one after AM_GNU_GETTEXT.
| > It seems to me that your definition of consistent is not what users
| > need.
|
| Do users *need* to omit the intl/ directory?
No, of course they don't. It makes things more easy well dealing with
merges etc. This is one of the main reasons I don't put source files
under CVS.
So since users don't _need_ to omit, as they don't _need_ not to omit
it, gettextize _needs_ to support this set up. Or rather, it would be
welcome from it to support it.
| > It turns out that, willing to do better than previous Gettext release,
| > gettextize suddenly does worse. The time where it did nothing to the
| > source made it, surprisingly, less useful.
|
| The newer gettextize does better for many people. It does worse for
| you, because you omit essential source files from the CVS.
I agree! I definitely agree! I'm saying there are means to satisfy
more people.
| > There are many people out there who are somewhat lost with Autoconf,
| > Automake, Libtool, Gettext etc. They need simple interfaces, in
| > particular when things go wrong.
| >
| > That's the role played by autoreconf.
|
| That's very clear. And it's not the purpose of gettextize, which is
| merely a migration tool.
I think I have understood that bit. I'm saying `gettextize can be
more useful, with a simple change'. I'm saying `that migration tool
can become more than a migration tool with a simple change of
paradigm: change the files if they appear to need it, not if some
other stimulus gave the impression they had to be updated'.
| So let's work on a "gettextreconf" tool that you could invoke from
| autoreconf.
Hm, it is not clear to me why a new tool would be needed, Bruno. I'm
just asking for grepping the files before updating them. I fail to
see the need for something else. A new tool is additional burden on
your shoulders, which is definitely not what I'm looking for.
- Re: CVS & Gettext, (continued)
- Re: CVS & Gettext, Akim Demaille, 2002/04/11
- Re: CVS & Gettext, Bruno Haible, 2002/04/11
- Re: CVS & Gettext, Akim Demaille, 2002/04/11
- Re: CVS & Gettext, Akim Demaille, 2002/04/11
- Re: CVS & Gettext, Bruno Haible, 2002/04/12
- Re: CVS & Gettext, Akim Demaille, 2002/04/18
- Re: CVS & Gettext, Bruno Haible, 2002/04/12
- Re: CVS & Gettext, Akim Demaille, 2002/04/18
- Re: CVS & Gettext, Bruno Haible, 2002/04/18
- Re: CVS & Gettext,
Akim Demaille <=
- Re: CVS & Gettext, Paul D. Smith, 2002/04/21
- Re: CVS & Gettext, Bruno Haible, 2002/04/23
- Re: CVS & Gettext, Paul D. Smith, 2002/04/23
- Re: CVS & Gettext, Paul Eggert, 2002/04/23