* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 11:59:57PM CEST:
On Monday 20 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 05:05:45PM CEST:
sc_tests_plain_automake:
- @if grep -v '^#' $(srcdir)/tests/*.test | grep -E ':[
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 10:58:05PM CEST:
On Monday 20 June 2011, Ralf Wildenhues wrote:
For example the parallel BSD makes tend to reuse shells for running
the recipe commands;
But only for the commands in the same recipe, right?
I think not.
I'm not so sure
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 11:12:23PM CEST:
Maybe we should also say that using TESTS_ENVIRONMENT to define a custom
test runner is now not only strongly deprecated (as it already was I hope),
No it wasn't. test runner is not a term I would recognize, btw.
but also
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 10:58:05PM CEST:
On Monday 20 June 2011, Ralf Wildenhues wrote:
For example the parallel BSD makes tend to reuse shells for running
the recipe commands;
But only for the commands in the
Stefano Lattarini wrote:
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 11:12:23PM CEST:
Maybe we should also say that using TESTS_ENVIRONMENT to define a custom
test runner is now not only strongly deprecated (as it already was I hope),
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 11:12:23PM CEST:
Maybe we should also say that using TESTS_ENVIRONMENT to define a custom
test runner is now not only strongly deprecated (as it already was I hope),
No it wasn't.
D'oh. I'll
On Tuesday 21 June 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 11:12:23PM CEST:
Maybe we should also say that using TESTS_ENVIRONMENT to define a custom
test runner is now not only
On Monday 20 June 2011, Stefano Lattarini wrote:
[SNIP]
To quote from the added NEWS entry:
- The parallel-tests driver is now implemented (partly at least) with
the help of automake-provided auxiliary scripts (e.g., `test-driver'),
instead of relying entirely on code in the
Stefano Lattarini wrote:
...
I've seen a few projects that require their automake-managed tests
be run sequentially. I suspect that some maintainers will not be eager
to adapt their tests to run in parallel solely to accommodate a newer
version of automake. If you have only a dozen or so
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
Ugh; 1/2 seems to be going into the wrong direction of changing test
code to work around suboptimal maintainer checks, so sorry for leading
you on a wrong path there again. 2/2 seems fine, thanks.
So should I drop the first patch
* Stefano Lattarini wrote on Tue, Jun 21, 2011 at 09:53:19AM CEST:
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 11:59:57PM CEST:
On Monday 20 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at
Hopefully the last iteration of the patches. A follow-up for
extending and fixing the documentation will go in a new thread.
Regards,
Stefano
Allow suffix-based definition of custom driver script for the
test scripts. These driver scripts will be responsible of
launching the tests (or their corresponding $(LOG_COMPILER), if
they have an associated one), interpreting and displaying the
test results, and writing the `.log' files.
This
On Tuesday 21 June 2011, Stefano Lattarini wrote:
On Monday 20 June 2011, Stefano Lattarini wrote:
[SNIP]
To quote from the added NEWS entry:
- The parallel-tests driver is now implemented (partly at least) with
the help of automake-provided auxiliary scripts (e.g.,
With this change, we improve the code creating the `test-suite.log'
global log and the console testsuite summary to make it able to
grasp multiple results per test script. This is required in order
to introduce the planned support for test protocols, like TAP and
SubUnit, which can indeed run
This refactoring should cause no API of functionality change,
and is meant only to simplify the future implementation of TAP
and SubUnit testsuite drivers. More precisely, our roadmap is
to move most of the testsuite driving features out of the
Automake-generated Makefiles, and into external
* Stefano Lattarini wrote on Tue, Jun 21, 2011 at 09:22:42PM CEST:
Hopefully the last iteration of the patches. A follow-up for
extending and fixing the documentation will go in a new thread.
Can you push your branch for this to a branch in the savannah git?
I'd like to take another look at
* Stefano Lattarini wrote on Sun, May 29, 2011 at 04:26:36PM CEST:
--- a/lib/am/configure.am
+++ b/lib/am/configure.am
@@ -22,7 +22,7 @@
## %MAKEFILE% is updated before considering the am--refresh target.
The comment up here ^^^ needs to be updated in this particular patch.
if %?TOPDIR_P%
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Tue, Jun 21, 2011 at 09:22:42PM CEST:
Hopefully the last iteration of the patches. A follow-up for
extending and fixing the documentation will go in a new thread.
Can you push your branch for this to a branch in
What's more: have you tried this patch on a nontrivial source tree
(where regenerating takes more than a second or so) with a few non-GNU
makes and GNU make? I kinda fear that it can cause an endless regen loop.
It might actually be smarter to use some newer BSD make features to
mark Makefile as
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Sun, May 29, 2011 at 04:26:36PM CEST:
--- a/lib/am/configure.am
+++ b/lib/am/configure.am
@@ -22,7 +22,7 @@
## %MAKEFILE% is updated before considering the am--refresh target.
The comment up here ^^^ needs to
* Stefano Lattarini wrote on Tue, Jun 21, 2011 at 10:43:06PM CEST:
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Sun, May 29, 2011 at 04:26:36PM CEST:
--- a/lib/am/configure.am
+++ b/lib/am/configure.am
@@ -22,7 +22,7 @@
## %MAKEFILE% is updated
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
What's more: have you tried this patch on a nontrivial source tree
(where regenerating takes more than a second or so) with a few non-GNU
makes and GNU make? I kinda fear that it can cause an endless regen loop.
It doesn't I think. See the
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Tue, Jun 21, 2011 at 10:43:06PM CEST:
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Sun, May 29, 2011 at 04:26:36PM CEST:
--- a/lib/am/configure.am
+++ b/lib/am/configure.am
On Tuesday 21 June 2011, Harlan Stenn wrote:
I'm trying to allow the selection of target man sections for each man
page at configure time.
For example, I have 'sntp.man.in' and 'sntp.mdoc.in' in the distribution
tarball, and at configure time stuff happens where the decision is
made as to
Hi Harlan,
* Harlan Stenn wrote on Tue, Jun 21, 2011 at 12:13:06PM CEST:
For example, I have 'sntp.man.in' and 'sntp.mdoc.in' in the distribution
tarball, and at configure time stuff happens where the decision is
made as to which version (man or mdoc) of the manual is to be installed,
and
Ralf,
That works just fine - thanks!
H
Hi Stefano,
Thanks for the suggestion - it was pretty much along the lines I thought
I'd have to go before Ralf posted.
H
Hello,
I'd like to know if there is a plan to switch to tar-pax or tar-ustar
(seems that pax support is broken in openbsd) as a default tar format.
Currently we have some problem in GNOME project with some modules
because the limitations of the current tar format
I'd like to know if would be
On Tue, 21 Jun 2011, Javier Jardón wrote:
I'd like to know if there is a plan to switch to tar-pax or tar-ustar
(seems that pax support is broken in openbsd) as a default tar format.
Currently we have some problem in GNOME project with some modules
because the limitations of the current tar
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
Does automake depend on 'tar' being GNU tar? If it will use any old
tar, then one would assume that it uses the default output format since
otherwise it might not know how to request some other format variant.
If it it used 'pax' then the
On Tue, 21 Jun 2011, Russ Allbery wrote:
The problem, of course, being that pax probably isn't available, which
makes it hard for a default choice.
As per WikiPedia:
Despite being standardized in 2001 by IEEE, as of 2010, pax enjoys
relatively little popularity and penetration rate.
pax
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
pax is required to be present in all conformant systems by Linux
Standard Base since version 3.0 (released on July 6, 2005),[2] but so
far few Linux distributions ship and install it by default. However,
most distributions include pax as a
33 matches
Mail list logo
