automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ok, new libtool for cygwin updates


From: Akim Demaille
Subject: Re: ok, new libtool for cygwin updates
Date: 12 Mar 2001 12:21:52 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)

"edward" <address@hidden> writes:

> cond3.test fails for three reasons.

Thanks, the fix has been applied.

>     3) cond3.test has an incorrect comparison test function (the sed script
> skips a line!) sorry, i'm not a big fan of sed. oh well.

I had reworked the snippet in the meanwhile.  It should be ok now.

> > FAIL: pr19.test
> 
> pr19.test fails for two reasons.
> 
>     1) foo.exe isn't cleaned properly (automake.in patch enclosed as
> automake-cygwin-exeext.patch)
> 
> --- automake.in.orig Sat Mar 10 07:14:42 2001
> +++ automake.in Sat Mar 10 07:15:21 2001
> @@ -1048,7 +1048,7 @@
>      # If OBJEXT/EXEEXT were not set in configure.in, do it, it
>      # simplifies our task, and anyway starting with Autoconf 2.50, it
>      # will always be defined, and this code will be dead.
> -    $output_vars .= "EXEEXT =\n"
> +    $output_vars .= "EXEEXT = address@hidden@\n"

No, we cannot do that.  We precisely issue this line when we have not
seen that AC_EXEEXT was used, so we cannot depend EXEEXT.  We need to
understand why it failed in pr19.  I suppose you are not running Unix
here?

What you observe is that the test itself is not ready to be run under
Cygwin, i.e., I guess its configure.in doesn't include AC_EXEEXT.
That's the problem to fix.


>     2) lines 4946-4947 of automake.in version 1.977
> 
>     # FIXME: nodist.
>     &push_dist_common ($pfx . $base . '.' . $ext);
> 
>     commenting out the last line removes foo.c (which is a temporary file)
> from the make distdir target, which fails because according to automake,
> foo.c is supposed to be redistributed. however, (gnu) make removes temporary
> files like foo.c (generated from foo.l). in my opinion, this is correct and
> should not be redistributed. the Makefile.am writer can always explicitly
> include foo.c if they really want to. from the comment in the automake.in
> file, it seems the automake peeps are aware of this. there are similar
> comments in automake.in with other generated files as well.

I leave this to Tom.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]