* Paul Eggert wrote on Tue, Jan 23, 2007 at 12:00:35AM CET:
>
> Thanks, please apply, except please change this comment:
[...]
> to this (just rewording):
Done, thanks. For autoconf-patches records, here's what I committed.
Cheers,
Ralf
2007-01-23 Ralf Wildenhues <[EMAIL PROTECTED]>
On 1/22/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
> > 2007-01-22 James Youngman <[EMAIL PROTECTED]>
> >
> > * m4/gnulib-common.m4 (AC_PROG_MKDIR_P): If AC_PROG_MKDIR_P
> > is already provided, call AC_SUBST on MKDIR_P anyway, since
> > the version of AC_PROG_MKDIR_P in
> > 2007-01-22 James Youngman <[EMAIL PROTECTED]>
> >
> > * m4/gnulib-common.m4 (AC_PROG_MKDIR_P): If AC_PROG_MKDIR_P
> > is already provided, call AC_SUBST on MKDIR_P anyway, since
> > the version of AC_PROG_MKDIR_P in Autoconf-2.61 (at least)
> > doesn't do that
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * lib/autoconf/programs.m4 (AC_PROG_MKDIR_P): Also
> AC_SUBST([MKDIR_P]), so that Automake < 1.10 will pick up its
> trace, if a package uses AC_PROG_MKDIR_P explicitly. The actual
> substitution will still be done by the speci
Hello Bruno, all,
* Bruno Haible wrote on Mon, Jan 22, 2007 at 05:48:53PM CET:
> Jim Meyering wrote:
> > I wonder which use case made it so using AC_SUBST wasn't an option.
>
> IIRC, it is when the user specifies
> ../path/configure --srcdir=../path
> with a relative pathname. Normally you can
Hello Jim, all,
* Jim Meyering wrote on Mon, Jan 22, 2007 at 03:52:21PM CET:
>
> dnl Do special magic for MKDIR_P instead of AC_SUBST, to get
> dnl relative names right.
> AC_MSG_RESULT([$MKDIR_P])
>
> The only case I can imagine is when MKDIR_P is specified
> as e.g., MKDIR_P='../bu
Bruno Haible <[EMAIL PROTECTED]> writes:
> Jim Meyering wrote:
>> I wonder which use case made it so using AC_SUBST wasn't an option.
>
> IIRC, it is when the user specifies
> ../path/configure --srcdir=../path
> with a relative pathname. Normally you can omit --srcdir, because configure
> finds
Jim Meyering wrote:
> I wonder which use case made it so using AC_SUBST wasn't an option.
IIRC, it is when the user specifies
../path/configure --srcdir=../path
with a relative pathname. Normally you can omit --srcdir, because configure
finds it by itself; then $ac_srcdir is an absolute path; th
Bruno Haible <[EMAIL PROTECTED]> wrote:
> James Youngman wrote:
>> The following patch fixes the problem. I'm not sure if it is
>> the *right* fix for the problem, since I have only been working with
>> Autoconf/Automake macros for ten years, and so I don't understand it
>> well enough yet.
>>
>>
James Youngman wrote:
> The following patch fixes the problem. I'm not sure if it is
> the *right* fix for the problem, since I have only been working with
> Autoconf/Automake macros for ten years, and so I don't understand it
> well enough yet.
>
> 2007-01-22 James Youngman <[EMAIL PROTECTED]>
On 1/22/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
James Youngman wrote:
> My generated aclocal.m4 file wants to substiture mkdir_p (courtesy of
> AM_PROG_MKDIR_P) but doesn't define AC_PROG_MKDIR_P. Nevertheless my
> gnulib-common.m4 file is indeed at serial 2 and the gl_INIT in
> gnulib/m4/g
On 1/22/07, Simon Josefsson <[EMAIL PROTECTED]> wrote:
"James Youngman" <[EMAIL PROTECTED]> writes:
> However, I think the problem is that on this system, the Makefile.in
> file is not actually using @MKDIR_P@ :-
Yes, I still get the same problem. I have tried Bruno's patch, but it
makes no di
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> "James Youngman" <[EMAIL PROTECTED]> writes:
>
>> However, I think the problem is that on this system, the Makefile.in
>> file is not actually using @MKDIR_P@ :-
>
> Yes, I still get the same problem. I have tried Bruno's patch, but it
> makes no differ
"James Youngman" <[EMAIL PROTECTED]> writes:
> However, I think the problem is that on this system, the Makefile.in
> file is not actually using @MKDIR_P@ :-
Yes, I still get the same problem. I have tried Bruno's patch, but it
makes no difference. The problem seems indeed to be that Makefile.i
Jim Meyering <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> This patch seem to cause plenty of build failures like this:
>
> Hi Simon,
>
> Thanks for the report.
> What version of autoconf are you using on that system?
dopio:/data/gnulib/build/gettime# autoconf --vers
James Youngman wrote:
> My generated aclocal.m4 file wants to substiture mkdir_p (courtesy of
> AM_PROG_MKDIR_P) but doesn't define AC_PROG_MKDIR_P. Nevertheless my
> gnulib-common.m4 file is indeed at serial 2 and the gl_INIT in
> gnulib/m4/gnulib-comp.m4 does indeed invoke AC_PROG_MKDIR_P.
Huh
I've just synced my CVS version of gnulib and it includes that
ChangeLog entry. I am using Autoconf version 2.61 and Automake
version 1.9.6.
My generated aclocal.m4 file wants to substiture mkdir_p (courtesy of
AM_PROG_MKDIR_P) but doesn't define AC_PROG_MKDIR_P. Nevertheless my
gnulib-common
Jim Meyering asked:
> That is, *if* gnulib needs to support autoconf older than 2.60.
Yes, the current minimum requirement is autoconf 2.59.
> Do any of you know of gnulib-using projects that require
> autoconf 2.59 or older?
Chasing the URLs in users.txt: Net::CDP, diffutils, gpg, gsasl, inetut
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Jim Meyering wrote on Sun, Jan 21, 2007 at 10:27:30PM CET:
>> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> > This patch seem to cause plenty of build failures like this:
>
>> What version of autoconf are you using on that system?
>
> AC_PROG_MKDIR_P i
* Jim Meyering wrote on Sun, Jan 21, 2007 at 10:27:30PM CET:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
> > This patch seem to cause plenty of build failures like this:
> What version of autoconf are you using on that system?
AC_PROG_MKDIR_P is new in Autoconf 2.60.
Cheers,
Ralf
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> This patch seem to cause plenty of build failures like this:
Hi Simon,
Thanks for the report.
What version of autoconf are you using on that system?
I tried to reproduce the failure like this:
cd /tmp
rm -rf x
/gnulib/gnulib-tool --dir x
Jim Meyering <[EMAIL PROTECTED]> writes:
> When building coreutils from scratch using "make -j3" on a uniprocessor
> system, I encountered this failure:
>
> ...
> mv configmake.h-t configmake.h
> mv stdint.h-t stdint.h
> test -d sys || mkdir sys
> test -d sys || mkdir sys
> rm -f sys/s
File exists
make[1]: *** [sys/time.h] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory `/f/w/cu/lib'
make: *** [all-recursive] Error 1
So I checked in this fix:
2007-01-18 Jim Meyering <[EMAIL PROTECTED]>
Use "$(MKDIR_P) sys&quo
23 matches
Mail list logo
