Re: [PATCH] {maint} Deprecate de-ansification support, it should go away in automake 1.12

On Wed, 15 Jun 2011, Stefano Lattarini wrote: Problem: it seems that there are few (and luckily only few) active packages that still use the `ansi2knr' option: 1. The latest version (8c) of the libjpeg implementation from IJG (Independent JPEG Group, ); see the `configur

[PATCH] check: don't use multi-line coloring for the report

less can't handle coloring which spans newlines because of performance reasons. Thus, color each line of the check report by its own. --- For reference, git had a similar problem and I talked to the less maintainer about the problem. Here is the resulting fix in git: http://repo.or.cz/w/git.git/

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On 06/15/2011 11:56 PM, Stefano Lattarini wrote: On Wednesday 15 June 2011, Ralf Corsepius wrote: In other words: IMO, automake is right in encouraging users to avod DISTCHECK_CONFIGURE_FLAGS, Actually, automake will discourage the use of AM_DISTCHECK_CONFIGURE_FLAGS *by developers*, not of D

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On 06/15/2011 07:57 PM, Eric Blake wrote: On 06/15/2011 11:31 AM, Ralf Corsepius wrote: DISTCHECK_CONFIGURE_FLAGS is useful in situations when a plain "./configure" is not meaningful to a source tree, i.e. when a source-tree mandatorily requires some configuration argument. Such a source-tree i

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On Wednesday 15 June 2011, Ralf Corsepius wrote: > On 06/15/2011 07:57 PM, Eric Blake wrote: > > On 06/15/2011 11:31 AM, Ralf Corsepius wrote: > DISTCHECK_CONFIGURE_FLAGS is useful in situations when a plain > "./configure" is not meaningful to a source tree, i.e. when a > source-tre

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On 06/15/2011 11:31 AM, Ralf Corsepius wrote: >>> DISTCHECK_CONFIGURE_FLAGS is useful in situations when a plain >>> "./configure" is not meaningful to a source tree, i.e. when a >>> source-tree mandatorily requires some configuration argument. >> Such a source-tree is violating GNU Coding Standard

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On 06/15/2011 11:16 AM, Stefano Lattarini wrote: > Hi Eric. >> As for a valid use of AM_DISTCHECK_CONFIGURE_FLAGS, the m4 package >> normally configures --without-changeword, but it is useful to have 'make >> distcheck' exercise the --with-changeword option to ensure that the code >> still compiles

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On 06/15/2011 02:18 AM, Ralf Corsepius wrote: > On 06/15/2011 09:40 AM, Stefano Lattarini wrote: >> On Tuesday 14 June 2011, Ralf Wildenhues wrote: >>> * Stefano Lattarini wrote on Fri, Jun 10, 2011 at 05:33:39PM CEST: > >>> I would suggest to at least discourage using this in the documentation. >

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On 06/15/2011 07:04 PM, Eric Blake wrote: On 06/15/2011 02:18 AM, Ralf Corsepius wrote: On 06/15/2011 09:40 AM, Stefano Lattarini wrote: On Tuesday 14 June 2011, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Fri, Jun 10, 2011 at 05:33:39PM CEST: I would suggest to at least discourage usi

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

Hi Eric. On Wednesday 15 June 2011, Eric Blake wrote: > On 06/15/2011 02:18 AM, Ralf Corsepius wrote: > > On 06/15/2011 09:40 AM, Stefano Lattarini wrote: > >> On Tuesday 14 June 2011, Ralf Wildenhues wrote: > >>> * Stefano Lattarini wrote on Fri, Jun 10, 2011 at 05:33:39PM CEST: > > > >>> I woul

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On 06/15/2011 09:40 AM, Stefano Lattarini wrote: On Tuesday 14 June 2011, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Fri, Jun 10, 2011 at 05:33:39PM CEST: I would suggest to at least discourage using this in the documentation. ... I agree, and I will make the change soon. Maybe I

[PATCHES v4] Allow custom testsuite drivers in Automake

OK, in truth these patches are not ready yet, but I'm posting this message anyway to tell any potential reviewer to ignore older versions of this series, and concentrate only on the oncoming one, in which I've done (or plan to do) various fixlets and improvements. These upcoming patches won't be p

Re: [PATCH] {maint} Deprecate de-ansification support, it should go away in automake 1.12

[adding automake list in CC: to make this more visible] Reference: On Tuesday 14 June 2011, Stefano Lattarini wrote: > Hello automakers. > > I recall that we agreed, in an older thread I can't find anymore, that > the s

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On Wednesday 15 June 2011, Ralf Corsepius wrote: > On 06/15/2011 09:40 AM, Stefano Lattarini wrote: > > On Tuesday 14 June 2011, Ralf Wildenhues wrote: > >> * Stefano Lattarini wrote on Fri, Jun 10, 2011 at 05:33:39PM CEST: > > >> I would suggest to at least discourage using this in the documentat

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

On Tuesday 14 June 2011, Ralf Wildenhues wrote: > * Stefano Lattarini wrote on Fri, Jun 10, 2011 at 05:33:39PM CEST: > > > > On Thursday 02 June 2011, Stefano Lattarini wrote: > > > Continuing with the good trend of avoiding to impinge on the use

Re: name of new pt-driver script

On Tuesday 14 June 2011, Ralf Wildenhues wrote: > [ adding the -patches list; sorry for appearing from the blue, the > rest of the discussion really was not really ontopic ... ] > > [ about the TAP/subunit proposal ] > > * Stefano Lattarini wrote on Tue, Jun 14, 2011 at 06:09:25PM CEST: > > On

Re: [REQUEST] Public temporary & rewindable branches for GSoC features

On Tuesday 14 June 2011, Ralf Wildenhues wrote: > Hi Stefano, > > * Stefano Lattarini wrote on Tue, Jun 14, 2011 at 05:55:02PM CEST: > > Would be ok with you if in the future I create some temporary branches > > *in the automake official repository* that I can rebase, edit, and delete > > at will?