Re: make dist

[Charles Levert]

* On Friday 2005-11-11 at 02:31:37 -0400, Tony Abou-Assaleh wrote:
> Found the problem. The automake version was 1.4, which caused a few things
> not to work. The syntax of some macros changed in later versions of
> automake.

Looking at the packages.debian.org web site,
I see that stable, unstable, and testing all
have 5 packages each for automake:  1.4, 1.6,
1.7, 1.8, and 1.9.  So which ones gets to have
the automake command name first in the PATH in
a default Debian install?

My system has a /etc/alternatives and a
/usr/sbin/alternatives for this sort of things,
but strangely just a hard link is used between
/usr/bin/automake and /usr/bin/automake-1.7
instead of relying on them.


> In 'configure.in', some languages were not included in ALL_LINGUAS that
> are in 'po/', which caused a problem with the 1.4 automake. More
> specifically, I had:
> 
> -ALL_LINGUAS="cs de el eo es et fr gl hr id it ja ko nl no pl pt_BR ru sl sv"
> +ALL_LINGUAS="bg ca cs da de el eo es et fr gl hr id it ja ko nb nl no pl 
> pt_BR ru sl sv tr"

Verified.
I have immediately committed a change to CVS
for this issue, since fixing it is obvious and
non-controversial.


> GNU Autoconf recommends renaming configure.in to configure.ac. The only
> benefit is a more meaningful name. Shall we?

One problem I see is that CVS doesn't support
renaming a file so that the log history for
the old configure.in would never be associated
with the log history for the new configure.ac.
You have to know about looking in both.
So I don't advocate doing this unless there is
a clearer benefit than a more meaningful name.


> 'GNU which' has a 'bootstrap' [1] script that serves the same function as
> our autogen.sh, but I think is better written (actually that's how I
> realized that I had an old automake). Can we borrow it? I could make the
> necessary renamings, modifications, and testings.

Maybe.  I see a "head -1" in this.  Won't that
cause some problems with newer coreutils
versions?  I wouldn't want to trade one problem
for another.


> The grep nightly build page [2] is back up and operational.

Thanks.

I have put back the paragraph pointing this it
from the devel web page.