Tom Tromey <[EMAIL PROTECTED]> écrit:
> > "François" == =?ISO-8859-1?Q?Fran=E7ois Pinard?= writes:
> François> Instead of packaging a `tar' file within a message, forcing
> François> an unavoidable unpacking step at the other extremity, I
> François> would favour a ready-to-send MIME multip
> "François" == =?ISO-8859-1?Q?Fran=E7ois Pinard?= writes:
François> Instead of packaging a `tar' file within a message, forcing
François> an unavoidable unpacking step at the other extremity, I
François> would favour a ready-to-send MIME multipart message, more
François> clear than Base64 i
Akim Demaille <[EMAIL PROTECTED]> écrit:
> | Then, it would be easy for testers like myself to run such a script
> | blindly, and mail you the resulting archive that contains all the
> | info you need. That way we won't waste too much time b/t us: you ask
> | "can you try X and mail me the outpu
Akim> Tom's scripts might help, indeed. Actually, this issue is so
Akim> generic that it is surprising that there are no tools already
Akim> developed. I wouldn't be surprised that François has something
Akim> automated?
As far as I know nobody has done much here.
My scripts have some nice feat
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
Erez> Question: is the "make check" interface and behavior expected to
Erez> be the same for all packages that use GNU auto*? For example,
Erez> I've never seen these debug*.sh scripts generated for libtool
Erez> and automake?
It is actuall
> "pipe" == Erez:
| Akim, you could help folks like me by distributing some sort of wrapper
| script that does the following:
|
| - run make test
| - for every failed test, run the debug*.sh script and record its output
| - remember to remove config.log etc. before running each debug*.sh te
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
Erez> That would be even better, b/c it'll extend to every package.
Erez> Question: is the "make check" interface and behavior expected to
Erez> be the same for all packages that use GNU auto*?
Nope. Right now the interface is that you run
In message <[EMAIL PROTECTED]>, Tom Tromey writes:
> > "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
>
> Erez> Akim, you could help folks like me by distributing some sort of
> Erez> wrapper script that does the following:
>
> Erez> - run make test
>
> It should be "make check".
Right.
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
Erez> Akim, you could help folks like me by distributing some sort of
Erez> wrapper script that does the following:
Erez> - run make test
It should be "make check".
Erez> - for every failed test, run the debug*.sh script and record its out
In message <[EMAIL PROTECTED]>, Akim Demaille writes:
>
[...]
> Thanks for the logs!
Let me know when I should run another set of tests.
> Akim
Akim, you could help folks like me by distributing some sort of wrapper
script that does the following:
- run make test
- for every failed te
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
Erez> Is there a new mailing list for cvs-logs as well? If so, how do
Erez> I subscribe to it?
Not set up yet, but I think we will propagate the former list of
members.
Akim
| I think I know what's wrong. You're using 'cc' instead of $CC somewhere. I
| have gcc installed on my machine, and no license for Solaris's /usr/ucb/cc
| compiler. So running cc fails.
That's correct, another user reported exactly the same failure. I
don't know yet how I will fix this, but
In message <[EMAIL PROTECTED]>, Akim Demaille writes:
>
> Hi Erez,
>
> I have fixed several mistakes in the test suite, so there should be
> less failures now.
>
> There are some I really don't understand, and I need your help (I
> can't reproduce them). But I would suggest that you pull out a
In message <[EMAIL PROTECTED]>, Akim Demaille writes:
>
> Hi Erez,
>
> I have fixed several mistakes in the test suite, so there should be
> less failures now.
>
> There are some I really don't understand, and I need your help (I
> can't reproduce them). But I would suggest that you pull out a
Hi Erez,
I have fixed several mistakes in the test suite, so there should be
less failures now.
There are some I really don't understand, and I need your help (I
can't reproduce them). But I would suggest that you pull out a fresh
Autoconf.
Ooops, btw people, we have to tell you we are moving
In message <[EMAIL PROTECTED]>, Akim Demaille writes:
>
> Wow, sounds like there is plenty of exciting things to check here. I
> have access to some Solarises, I will try with them to see if I can
> get all the data I need. Thanks a lot for the report (and don't lose
> these guys :).
>
> Akim
Wow, sounds like there is plenty of exciting things to check here. I
have access to some Solarises, I will try with them to see if I can
get all the data I need. Thanks a lot for the report (and don't lose
these guys :).
Akim
In message <[EMAIL PROTECTED]>, Akim Demaille writes:
> > "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
>
[...]
> Erez> After these two happen, I'd like to test autoconf on all of my
> Erez> platforms. I do it in two ways: (1) run make test, and (2) use
> Erez> it in my am-utils package.
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
Erez> That's good news, Akim.
Oh yes it is! :)
Erez> Now, do you have a schedule for when a feature freeze will
Erez> happen, and when this autoconf will work with automake 1.4a?
We've not talked about this yet, but personally I'm not s
Hello!
> Now, do you have a schedule for when a feature freeze will happen, and when
> this autoconf will work with automake 1.4a? After these two happen, I'd
What is actually automake 1.4a? Do you mean the current Automake from the
CVS or a certain snapshot?
Why do you say that it "will work"
The latest automake (off of cvs) doesn't yet handle the
AC_CONFIG_FILES()/AC_OUTPUT split. This is only an autoconf warning now,
but it means that automake is not user-releasable yet. (Unless you guys
want to be bombarded with tons of similar questions.)
Automake also doesn't handle the --build
That's good news, Akim.
Now, do you have a schedule for when a feature freeze will happen, and when
this autoconf will work with automake 1.4a? After these two happen, I'd
like to test autoconf on all of my platforms. I do it in two ways: (1) run
make test, and (2) use it in my am-utils package
Yep, sorry, this is also an issue to solve. I had used Automake 1.4a
which uses AM_MISSING with two args, and an executable missing. When
I fell back to 1.4, I forgot to downgrade the use of AM_MISSING. It
will be done.
Meanwhile, I'd suggest that you
AVAILABILITY
The latest version
Akim Demaille wrote:
> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> Ralf> => tests/Makefile.in is missing from CVS.
>
> Heck! I'm sorry, I'm deeply sorry, I plead guilty :(
>
> CVS Autoconf is to be used with Automake 1.4, not 1.4a (well, you can,
> but then you have to update
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> => tests/Makefile.in is missing from CVS.
Heck! I'm sorry, I'm deeply sorry, I plead guilty :(
CVS Autoconf is to be used with Automake 1.4, not 1.4a (well, you can,
but then you have to update the m4/*.m4 files and aclocal.m4).
Akim Demaille wrote:
> Hi!
>
> I'm sorry for people who don't read autoconf-patches, there's a news I
> should have sent before: we have caught up the difference between CVS
> Autoconf and FTP Autoconf. The latter has been removed, and people
> who really depend a ultra-new Autoconf are encoura
26 matches
Mail list logo
