Alexandre Duret-Lutz wrote:
>
> Could you run the testsuite, while you are at it?
$ make check
[...]
PASS: yaccvpath.test
===
All 344 tests behaved as expected (4 expected failures)
===
make[2
>>> "Eric" == Eric Blake <[EMAIL PROTECTED]> writes:
Eric> SUCCESS! With your patch to XFile.pm, I was able to do:
Eric> $ cd automake
Eric> $ touch Makefile.am
Eric> $ make
Eric> cd . && \
Eric> perllibdir=./lib /home/eblake/automake/automake --libdir=lib --gnu
Eric> Makefile
Eric> cd
SUCCESS! With your patch to XFile.pm, I was able to do:
$ cd automake
$ touch Makefile.am
$ make
cd . && \
perllibdir=./lib /home/eblake/automake/automake --libdir=lib --gnu
Makefile
cd . && /bin/sh ./config.status Makefile
config.status: creating Makefile
Making all in .
[...]
$ cvs up Makef
| Index: lib/Automake/XFile.pm
| ===
| RCS file: /cvs/automake/automake/lib/Automake/XFile.pm,v
| retrieving revision 1.1
| diff -u -r1.1 XFile.pm
| --- lib/Automake/XFile.pm 2001/10/02 17:17:45 1.1
| +++ lib/Automake/XFile.pm 2002/0
>>> "Eric" == Eric Blake <[EMAIL PROTECTED]> writes:
Eric> OK, I really want this bug gone. So I did some more research, this time
Eric> with a fresh copy of automake from the head of CVS (no patches
Eric> applied). I'm using a cygwin text mount, so every file has \r\n on
Eric> every line a
OK, I really want this bug gone. So I did some more research, this time
with a fresh copy of automake from the head of CVS (no patches
applied). I'm using a cygwin text mount, so every file has \r\n on
every line after the CVS update. If I understand XFile.pm correctly,
this means that automake
>>> "Eric" == Eric Blake <[EMAIL PROTECTED]> writes:
[...]
Eric> So my previous patch did not solve the file read problem, and it hurt
Eric> the file write problem as well (Makefile.in was being generated with
Eric> some lines having \r\r\n, and perl's chomp only removes one of the two
Eric>
I take back this previous email. Even with my patch below, I'm still
getting failures when trying to repeat my work:
$ cd ~/automake
$ perllibdir=./lib ./automake --libdir=lib --gnu
Makefile.am:34: bad macro name `--regex'
So my previous patch did not solve the file read problem, and it hurt
th
News on Automake 1.5d on cygwin. I downloaded tag Release-1-5d (as
opposed to the cvs head), and from my cygwin textmount, it wouldn't even
configure without coaxing:
$ make
cd . && perllibdir=./lib /home/eblake/automake/aclocal --acdir=m4 -I
/home/eblake/automake/m4
cd . && \
perllibdir=./lib
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> A problem with line termination in automake was reported on the
Tom> Classpath list. I don't understand why this happens, since in
Tom> Automake::XFile we only call binmode when writing, not when reading.
How does Automake 1.5d behave?
ssage ---
Message-ID: <[EMAIL PROTECTED]>
Date: Sat, 09 Feb 2002 11:35:19 -0700
From: Eric Blake <[EMAIL PROTECTED]>
Organization: BYU Student
MIME-Version: 1.0
To: [EMAIL PROTECTED]
CC: Classpath list <[EMAIL PROTECTED]>
Subject: Re: build question
References: <[EMAIL PROTECTED]>
What do you want me to do to test this out, so we can fix the root of
the problem?
Tom Tromey wrote to the Classpath list <[EMAIL PROTECTED]>:
>
> > "Eric" == Eric Blake <[EMAIL PROTECTED]> writes:
>
> Eric> automake: native/jni/java-lang/Makefile.am: `\' is not a standard
> Eric> libtool l
12 matches
Mail list logo