Re: libtool 1.5.6 still not supporting make distcheck

[Ralf Wildenhues]

[ slightly reordered your answers for ease of consistent answers ]

* Sean Dague wrote on Tue, Nov 16, 2004 at 05:56:11PM CET:
> On Mon, Nov 15, 2004 at 04:20:05PM +0100, Ralf Wildenhues wrote:
> > * Sean Dague wrote on Thu, Nov 11, 2004 at 09:45:40PM CET:
> > > The issue I reported a couple weeks ago is still there.  We have now 
> > > tracked
> > > down based on a number of versions of libtool to figure out what works and
> > > what doesn't.
> > 
> > First: Your build is not VPATH clean, because you are doing a lot of
> > symlinking by hand in several Makefile.am's.  
> 
> Yes, we are doing this because there is a need to build test cases which use
> our real code, and the symlink solution seemed to be the most workable.

Sure, the idea seems fine to me.

> > BTW, you did not mention your system at all, neither whether you are
> > doing a VPATH build or not.  All of this would have been helpful (still
> > is if the problem remains unsolved), also whether or not an installed
> > version of your package exists on your system or not.
> 
> Excuse my ignorance, but I'm not sure of what a VPATH build is.

Where the build tree is different from the source tree.
(It's called that way because the necessary `make' feature has to do
with the VPATH make variable).

Example:  Your source is in /tmp/openhpi/.  I do:

$ mkdir /tmp/build-openhpi && cd /tmp/build-openhpi
$ ../openhpi/configure -C 
$ make

Actually, to find such and other dependency bugs quickly, I replaced the
`make' with:

$ make -j2 distcheck

> > First, you should be using $(LN_S) together with AC_PROG_LN_S for symlinks
> 
> Agreed, making that change now
> 
> > second you should link to $(srcdir)/relpath/$@ instead
> 
> Also agreed, making that change now

Watch out.  You link to some built sources and some non-built sources.
When trying your code, I replaced the link-setting snippets with
something like

 $(REMOTE_LIB_SOURCES):
        if test ! -f $@ -a ! -L $@; then \
               if test -f ../$@; then \
                       $(LN_S) ../$@ $@; \
               else \
                       $(LN_S) $(srcdir)/../$@ $@; \
               fi; \
        fi

so that they would still work regardless where the file-to-link-to was
found.  Also, note that this is safe only if $(REMOTE_LIB_SOURCES)
contains only target names in the current directory (also explained in
Autoconf docs).

> > third you should probably instead just
> > be using AC_CONFIG_LINKS and be happy that you don't have to care about
> > this yourself.  All explained in Autoconf docs.
> 
> I'll look into that possibility as well, though wouldn't that require
> centralizing all linking code to configure.ac, instead of letting the
> Makefile.am deal with it locally?

Yes.  This is arguably a deficiency.  However, first it replaces each
snippet as above to one short line, second you probably could move it
into a separate .m4 file where you define a macro which you then use in
configure.ac.  I don't know if the latter is worth the effort.

> > Apart from these changes, `make distuninstallcheck' is the first part of
> > `make distcheck' to complain, and it complains about some files which
> > `make uninstall' misses to remove.  This is with the HEAD branch as well
> > as branch-1-5 of libtool.
> > 
> > So, can you try either the patch from
> > http://lists.gnu.org/archive/html/bug-libtool/2004-10/msg00170.html
> > and possibly branch-2-0 from CVS?  Please tell us your findings.
> 
> I will check it out and report my results.

Great!

> The system I am running on is Mandrake Linux 10.1 on x86 (we've seen the
> failure with FC3 as well).
> 
> There is not and installed version of the libraries on my system.

Good to know.

If this thread gets more application-dependent and less
libtool-dependent, we should probably move to some openhpi-related list
(Cc: me then, please, as I don't read any of those).

Regards,
Ralf