[ITA] cppunit 1.10.2 - A C++ unit testing framework (REVISED)

[Brian Dessent]

Dave Korn wrote:

>   Cygwin uses 'alternatives' to manage automake:
> 
> /artimi/software/firmware $ /usr/sbin/update-alternatives --config automake
> 
> There are 8 programs which provide 'automake'.
> 
>   Selection    Command
> -----------------------------------------------
>    1           /usr/bin/automake-1.4
>    2           /usr/bin/automake-1.5
>    3           /usr/bin/automake-1.6
>    4           /usr/bin/automake-1.7
>    5           /usr/bin/automake-1.8
>    6           /usr/bin/automake-1.9
>    7           /usr/bin/automake-1.10
> *+ 8           /usr/share/autotools/am-wrapper.sh
> 
> Enter to keep the current selection[+], or type selection number:
> 
>   The am-wrapper script is the one that tries to deduce and reuse the original
> version used to first build the file, IIUIC.

I'm pretty sure that's not what's going on here; you'd see the same
thing without alternatives or am-wrapper.sh because automake encodes the
version number used to build the generated Makefile.in and then directly
invokes that version as automake-n.n, bypassing all of the above.

However, when you re-run autoreconf --force --verbose --install it is
supposed to regenerate everything using the latest version, which means
this embedded automake-1.9 reference should .  I'm not sure why in Ross'
case it's still trying to call automake-1.9 whereas in David's case it's
not, but Ross also mentioned that he'd edited the cygport file to remove
the autoreconf line which is definitely wrong -- running autoreconf is
what should remove this dependency on the older version.  Ross: try just
unpacking the source tarball into a directory and running "autoreconf
--force --verbose --install" there.  If that doesn't work then we need
to investigate why, outside of the context of cygport.

Brian