Hello,
On Fri, Apr 21, 2006 at 10:55:01AM +0200, Ralf Wildenhues wrote:
> * Stepan Kasal wrote on Fri, Apr 21, 2006 at 10:40:04AM CEST:
> > > This would silently break lots of `bootstrap' scripts that call
> > > aclocal
> > > automake
> > > autoconf
> >
> > It wouldn't break them, I think,
[ automake-patches dropped ]
Hi Stepan,
* Stepan Kasal wrote on Fri, Apr 21, 2006 at 10:40:04AM CEST:
>
> BTW, you said:
> > This would silently break lots of `bootstrap' scripts that call
> > aclocal
> > automake
> > autoconf
> >
> > in that order, instead of the other way. (Remember th
Hello,
I proposed:
> > > Stepan> I would suffice if autoconf, when called in 3) updated
> > > ./configure.
[plus]
> > $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/configure
On Thu, Apr 20, 2006 at 04:51:26PM +0200, Ralf Wildenhues wrote:
> Also, you are munging time stamps behind
* Stepan Kasal wrote on Thu, Apr 20, 2006 at 02:52:31PM CEST:
> On Thu, Apr 20, 2006 at 02:03:14PM +0200, Alexandre Duret-Lutz wrote:
> > Stepan> I would suffice if autoconf, when called in 3) updated ./configure.
> > Stepan> (It presents only minimum of extra work.)
> >
> > I don't think it wor
Hello Alexandre,
On Thu, Apr 20, 2006 at 02:03:14PM +0200, Alexandre Duret-Lutz wrote:
> Stepan> I would suffice if autoconf, when called in 3) updated ./configure.
> Stepan> (It presents only minimum of extra work.)
>
> I don't think it works :
>
> - if automake is called by a rebuild rule
>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:
[...]
Stepan> I would suffice if autoconf, when called in 3) updated ./configure.
Stepan> (It presents only minimum of extra work.)
I don't think it works :
- if automake is called by a rebuild rule to rebuild one
Makefile.in with
Hello Alexandre,
On Thu, Apr 20, 2006 at 09:12:01AM +0200, Alexandre Duret-Lutz wrote:
> >>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>
> adl> Here is my attempt at checking Autoconf version in aclocal.m4.
...
> Here is a second attempt [...]
...
>* It does not pollute acloc
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> Here is my attempt at checking Autoconf version in aclocal.m4.
adl> It would be nice if someone could suggest a better way to retrieve
adl> the Autoconf version:
Here is a second attempt that I think is superior to the
previous
On Tue, Apr 18, 2006 at 10:06:40AM -0600, Bob Proulx wrote:
> Noah Misch wrote:
> > Alexandre Duret-Lutz wrote:
> > > I'm leery of assuming that Autoconf's version will always be at
> > > this spot in the output of --version. Sometimes people customize their
> > > copy and tweak --version to refle
Noah Misch wrote:
> Alexandre Duret-Lutz wrote:
> > I'm leery of assuming that Autoconf's version will always be at
> > this spot in the output of --version. Sometimes people customize their
> > copy and tweak --version to reflect so:
> > ...
> > % gcc --version
> > gcc (GCC) 4.0.3 (Debian 4.0.3-1
>> This requirement is reflected in the SunOS man page, (from
>> SunOS 5.5.4, IIRC)
>
> Hmmm, "SunOS 5.5.4"? There's no such version.
It's actually 5.5.1; I wasn't able to access the machine until
I came back to work today, after the Easter break, and was quoting
from a failing memory :-( Perha
Hello,
On Mon, Apr 17, 2006 at 12:02:38AM +0100, Keith Marshall wrote:
> Perhaps that was an unnecessarily harsh criticism, sorry.
no problem. I'm afraid my answer was also a bit harsh:
> > Second, let me remind me that we are currently in a freeze; [...]
>
> I wasn't suggesting that you shoul
Hello,
On Sun, Apr 16, 2006 at 09:31:36PM -0700, Paul Eggert wrote:
> Stepan Kasal <[EMAIL PROTECTED]> writes:
> > sed '/datarootdir/{p
> > }'
> > is correct according to POSIX, yet I think some implementations are not
> > able to parse it.)
>
> Hmm, which would those be? [...] I just checked 7th
Keith Marshall <[EMAIL PROTECTED]> writes:
> This requirement is reflected in the SunOS man page, (from SunOS 5.5.4,
> IIRC)
Hmmm, "SunOS 5.5.4"? There's no such version.
The Sun 'sed' pages that I looked at (from SunOS 5.8 and SunOS 5.10)
don't require that _every_ command be separated by new
Stepan Kasal <[EMAIL PROTECTED]> writes:
> semicolons cannot be used inside
> curly braces, so you have to write, for example:
>
> sed '/datarootdir/{
> p
> q
> }'
>
> IIRC, Autoconf was recently fixed to obey this rule,
Yes, here:
http://lists.gnu.org/archive/html/autoconf-patch
On Sun, Apr 16, 2006 at 12:58:08PM +0200, Alexandre Duret-Lutz wrote:
> I'm leery of assuming that Autoconf's version will always be at
> this spot in the output of --version. Sometimes people customize their
> copy and tweak --version to reflect so:
>
> % gcc --version
> gcc (GCC) 4.0.3 (Debian
On Sunday 16 April 2006 7:36 pm, Stepan Kasal wrote:
> Second, let me remind me that we are currently in a freeze; I believe
> that this type of changes should be put off after 2.60, unless it is
> supported by a real-world problem report.
I wasn't suggesting that you should immediadely rush to ch
Hello,
On Sun, Apr 16, 2006 at 12:58:08PM +0200, Alexandre Duret-Lutz wrote:
> [...] --version really is a human thing in my opinion.
>
> Anyway it sure feels better to directly compare the value of
> m4_PACKAGE_VERSION in one Autoconf with the value of
> m4_PACKAGE_VERSION in another, without t
Hello,
On Sun, Apr 16, 2006 at 06:58:28PM +0100, Keith Marshall wrote:
> On Sunday 16 April 2006 1:41 pm, Andreas Schwab wrote:
> > Keith Marshall <[EMAIL PROTECTED]> writes:
> > > On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote:
> > > > We both use the same pattern
> > > > `sed -n '/@
Keith Marshall <[EMAIL PROTECTED]> writes:
> Let me turn that around, and ask if you can provide any documentary
> evidence, other than anecdotal, to suggest that this use of semicolons
> *should* be supported? SUSv3 *expressly* demands that sed directives be
> separated by newlines:
> http://w
On Sunday 16 April 2006 1:41 pm, Andreas Schwab wrote:
> Is there any evidence that there exists a sed implementation that does
> not support the semicolon as command separator? Note that the thread
> you quote above is _not_ about semicolons being unsupported, but rather
> about missing ones. Au
On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote:
> On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote:
> > here's a patch that I think does more or less what Bruno's patch
> > intends to do, against current CVS.
>
> I worked on the same issue. We both use the same pattern
>
Keith Marshall <[EMAIL PROTECTED]> writes:
> On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote:
>> On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote:
>> > here's a patch that I think does more or less what Bruno's patch
>> > intends to do, against current CVS.
>>
>> I worked on
>>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes:
SK> Hello,
SK> On Thu, Apr 13, 2006 at 08:52:48PM +0200, Alexandre Duret-Lutz wrote:
>> Or can we tweak Autoconf to make its version more accessible?
SK> what would be wrong with parsing `autoconf --version' or
SK> `autom4te --version'? (
Stepan Kasal <[EMAIL PROTECTED]> writes:
> --- lib/Automake/FileUtils.pm 2006-04-14 09:25:00.0 +0200
> +++ lib/Automake/FileUtils.pm 2006-04-14 09:45:44.0 +0200
> @@ -73,6 +73,9 @@
>$optional = 1
> if $file_name =~ s/\?$//;
>
> + return "-"
> +if $file_name eq "-";
Hello,
On Thu, Apr 13, 2006 at 08:52:48PM +0200, Alexandre Duret-Lutz wrote:
> Or can we tweak Autoconf to make its version more accessible?
what would be wrong with parsing `autoconf --version' or
`autom4te --version'? (At least as a fallback, when autom4te is
not able to handle stdin.)
echo
| The patch to add AC_PREREQ to AM_PATH_LISPDIR is necessary not to
| prevent the failures Noah described, but simply to prevent users from
| trying to use the macro with an Autoconf version that is too old and
| does not cause `${datarootdir}' to be defined.
I was merely explaining why aclocal co
Hi Alexandre,
* Alexandre Duret-Lutz wrote on Thu, Apr 13, 2006 at 09:54:31AM CEST:
>
> (AC_PREREQ would only prevent downgrading autoconf without
> rerunning automake, while we are discussing about upgrading it
> too.)
The patch to add AC_PREREQ to AM_PATH_LISPDIR is necessary not to
prevent the
Hello Alexandre,
> On Thu, Apr 13, 2006 at 09:54:31AM +0200, Alexandre Duret-Lutz wrote:
> > [..] aclocal could output some code in
> > aclocal.m4 to ensure that the autoconf version that reads
> > aclocal.m4 is the same as the version that was traced to
> > generate it.
...
> > In case this che
On Thu, Apr 13, 2006 at 09:54:31AM +0200, Alexandre Duret-Lutz wrote:
> Noah:
> | `automake' can generate a Makefile.in that does not fit
> | `configure' if the version of Autoconf it uses to trace
> | `configure.ac' differs from the version used to generate
> | `configure'.
>
> The Autoconf versi
Noah:
| `automake' can generate a Makefile.in that does not fit
| `configure' if the version of Autoconf it uses to trace
| `configure.ac' differs from the version used to generate
| `configure'.
The Autoconf version used by Automake should also be the same
used by aclocal. Maybe aclocal could ou
Hi Stepan,
* Stepan Kasal wrote on Wed, Apr 12, 2006 at 09:47:36PM CEST:
> On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote:
> > here's a patch that I think does more or less what Bruno's patch
> > intends to do, against current CVS.
>
> I worked on the same issue [..]
and your pa
Hello,
On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote:
> here's a patch that I think does more or less what Bruno's patch
> intends to do, against current CVS.
I worked on the same issue. We both use the same pattern
`sed -n '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...
* Stepan Kasal wrote on Wed, Apr 12, 2006 at 02:17:53PM CEST:
> The proposal
>
>http://lists.gnu.org/archive/html/bug-autoconf/2005-03/msg00027.html
>
> goes in this direction, but needs more work, as Bruno said.
> I might do that work when we come to an agreement what we want.
I know you wo
Hi Stepan, Noah,
Thanks to both of you for the analyses!
* Stepan Kasal wrote on Wed, Apr 12, 2006 at 02:17:53PM CEST:
>
> Problem A:
> a script.sh.in starts with
>
> prefix = @prefix@
> doc = @docdir@
But maybe that would have to be
prefix="@prefix@"
doc="@docdir@"
or similarly. This is
Hello,
as Bruno said, ``GCS doesn't mandate that the build will break.''
I think we could be more careful and include some workarounds.
Generally, there are two problem situations:
Problem A:
a script.sh.in starts with
prefix = @prefix@
doc = @docdir@
this has to be fixed by adding `dataroot
36 matches
Mail list logo
