This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ok, new libtool for cygwin updates


"edward" <tailbert@Yahoo.com> 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 = \@EXEEXT\@\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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]