Re: P.S. Automake 1.4f is broken

[Gary V. Vaughan]

On Sun, Sep 09, 2001 at 04:58:39AM -0700, Bruce Korb wrote:
> "Gary V. Vaughan" wrote:
> 
> > Ah, okay.  I thought you meant AutoGen was hosed.
> 
> It is, too.  First, "snprintfv/config/depcomp" couldn't be found during
> a "make distcheck".  Since it was a generated file, I added it to the
> "EXTRA_DIST" for that directory.

As I understand it (which may be not very much -- I held out on
Automake 1.4 until a feww weeks ago) depcomp should not be needed by
an installer, it used to generate dependencies for the developer,
which are included into the Makefile.in's rolled into the distribution
tarball with `make distcheck'.

> Then there are these:
> 
> > automake: Makefile.am: installing `./COPYING'
> > Use of uninitialized value in string eq at /usr/local/bin/automake line 
> > 5192.

I have been getting this in the libltdl bootstrap sequence since I
upgraded to 1.5, but haven't looked any deeper since it doesn't seem
to affect the rest of the build.  I'm glad it is not just me going
insane :-D  Besides I only have a Perl-Fu white belt, so much the
detail is beyond my ken.

> > Use of uninitialized value in hash element at \
> > /usr/local/bin/automake line 1751.automake: configure.in: installing 
> > `config/depcomp'

I haven't seen this one before...

> > sub derive_suffix
> > {
> >     my ($source_ext) = @_;
> >  
> >     # FIXME: hard-coding `o' is a mistake.  Doing something
> >     # intelligent is harder.
> >     while ($extension_map{$source_ext} eq ''  ###  line 5192
> >            && $source_ext ne 'o'
> >            && defined $suffix_rules{$source_ext})
> >     {
> >         $source_ext = $suffix_rules{$source_ext};
> >     }
> 
> > sub handle_single_transform_list ($$$@)
> > {
> >     my ($var, $derived, $obj, @files) = @_;
> >     my @result = ();
> >     my $nonansi_obj = $obj;
> >     $nonansi_obj =~ s/\$U//g;
> >     my %linkers_used = ();
> >     foreach (@files)
> >     {
> [error test]
> >         next if ! /^(?:(.*)\/)?([^\/]*)\.(.*)$/;
> >         my $full = $_;
> >         my $directory = $1 || '';
> >         my $base = $2;
> >         my $extension = $3;
> [comment]
> >         my $renamed = 0;
> >         my ($linker, $object);
> >         $extension = &derive_suffix ($extension);
> >         my $lang = $languages{$extension_map{$extension}};  ### line 1751
> 
> and:
> 
> > Making distclean in .
> > make[3]: Entering directory 
> > `/home/bkorb/ag/ag/autogen-5.2.10/=build/snprintfv'
> > [...]
> > make[2]: Entering directory `/home/bkorb/ag/ag/autogen-5.2.10/=build'
> > rm -f Makefile  stamp-h stamp-h[0-9]*
> > rm -f config.h
> > rm -f TAGS ID
> > make[2]: Leaving directory `/home/bkorb/ag/ag/autogen-5.2.10/=build'
> > rm -f config.status config.cache config.log
> > make[1]: Leaving directory `/home/bkorb/ag/ag/autogen-5.2.10/=build'
> > Error: files left after distclean
> > make: *** [distcheck] Error 1
> 
> Ah.  I see the problem.  Schizophrenic builds do not work because
> there is no way to pass VPATH through to scripts and programs
> that build targets.  VPATH is a command line "feature".

Aha!  I have been getting reports that CVS libtool no longer builds
correctly with builddir != srcdir.  I've burnt a couple of hours
trying to figure out why libltdl/libtool doesn't arrive in the build
tree.  I'll bet it is the same problem, and that it will work if I
downgrade to Automake 1.4-p5 again...

> I fixed
> this problem by having builddir != srcdir builds sym-link
> the source tree into the build tree.  Someone in automake land
> decided to verify that "make distclean" was successful by looking
> for "files" in the build tree and accepting the sym-links as
> files:
> 
> >           && cd $(distdir)/=build \
> >           && ../configure --srcdir=.. --prefix=$$dc_install_base \
> >           && [...] \
> >           && $(MAKE) $(AM_MAKEFLAGS) distclean \
> >           && rm -f $(distdir).tar.gz \
> >           && (test `find . -type f -print | wc -l` -eq 0 \
> >              || (echo "Error: files left after distclean" 1>&2; \
> >                  exit 1) )
> 
> I think that VPATH is a broken concept.  This final test
> needs to be a WARNING, not an error.  Automake is broken.

VPATH is good in principle, but it is always hard to support.  In
build tools as well as development projects.  But I agree with your
diagnosis.

> > For gnuprog2 we are very much on the bleeding edge I'm afraid.
> 
> Is there a compelling reason for using bleeding edge?
> I'm quite tired of the blood letting, I must say.

For AutoGen, no reason at all.  Autoconf-2.13, Automake-1.4p5 and
Libtool 1.4.2 will be just fine.  [[I have delayed 1.4.2 far 24 hours
because I think I have found a more elegant solution to the Solaris
problem, that requires more testing]]

> That kills my last release.  *sigh*.

Sorry about that =(O|

> > M4-1.4q is available from savannah in parallel with libtool.
> 
> I need this, too?

To perform a full build of gnuprog2, yes.  For AutoGen, 1.4 is fine.

Cheers,
        Gary.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/