Re: gettextize attempts to mangle configure.in and Makefile.am

[James Henstridge]

Bruno Haible wrote:

> James Henstridge writes:
>  
>
> > The latest version of gettext's gettextize script tries to modify the 
> > toplevel configure.in and Makefile.am files when run.  This is an 
> > undocumented side effect, and could very well introduce bugs.
> >    
>
> On the other hand, gettextize now makes the installation/upgrade to a
> new gettext version a breeze.
>
>  
>
> > If gettextize is going to do these sort of modifications, it should be 
> > an option, and off by default.
> >    
>
> They are on by default because they are correct far more often than
> incorrect. And for the cases where they are incorrect:
>  - All actions are logged on stdout,
>  - All actions are noted in detail in the ChangeLog files.
>  - Every file being modified is backed up.
For the packages I maintain, there are multiple people building out of 
CVS.  We don't check in generated files or stuff maintained by other 
people that gets copied in by the various build tools (libtool, 
automake, etc).  This works very well (developers check out from CVS, 
then run a script that calls aclocal, libtoolize, automake, etc), and 
gets rid of problems where many revisions are created when developers 
have different versions of build tools (eg. developer A creates a 
generated file with one version of a tool and checks it in.  Another 
developer regenerates the same file with a different version and gets 
signficantly different output.  Repeat for many large deltas).

The one exception to this was gettext, starting round version 0.10.36 (I 
am not sure exactly which version).  When it started writing to a change 
log, we started getting lots of useless messages in po/ChangeLog when 
people checked stuff in.  This was a pretty major annoyance until the 
--no-changelog argument was added.

Now you added this code to make modifications to configure.in and 
Makefile.am (I am not sure why they are required -- previous versions 
managed without them).  These changes are definitely not desired.

Why must gettext act so differently to the rest of the GNU build chain?

> > These sort of modifications should be done by maintainers (if they
> > are going to be done at all).
> >    
>
> gettextize takes some burden off the maintainers.
>  
Not knowing which file in my project the new version of gettext is going 
to munge next does not inspire confidence.

James.

--
Email: address@hidden
WWW:   http://www.daa.com.au/~james/