| Hi,
| My general impressions after 1 day of autoconf 2.50 use.
|
| - The backtrace facility is really a nice feature.
Cool :)
| - "config.status much faster on most architectures"
| but configure is slower. Here are the timings of gettext's configure:
|
| autoconf 2.13: 23.0 sec rea
On 15 Jun 2001, Akim Demaille wrote:
> But I can tell you the tests are much better now, so I think it
> deserves this difference. Have a look at config.log too. The point
> is really to let the maintainer find everything she needs in there.
> And BTW, if you lack some information in it, ask fo
Masao Uebayashi writes:
> Hello,
>
> Whether a option found by "configure"'s test is used (enabled) by
> default is decided by the auther of the "configure" script, but I want
> to override it as "no", that is, I want to use options which I
> explicitly specify by "--enable-*".
grep the autocon
| On 15 Jun 2001, Akim Demaille wrote:
| > But I can tell you the tests are much better now, so I think it
| > deserves this difference. Have a look at config.log too. The point
| > is really to let the maintainer find everything she needs in there.
| > And BTW, if you lack some information in
When trying to generate more than 250 files with one configure script
(like the kdebase package wants to do) you'll hit the nesting limit of m4
(due to the fact that loops are implemented through recursion). Currently
there is no way increase this limit from the autoconf invocation. How
about ad
> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
Andreas> When trying to generate more than 250 files with one
Andreas> configure script (like the kdebase package wants to do)
Wow!!!
Andreas> you'll hit the nesting limit of m4 (due to the fact that
Andreas> loops are implemented th
Akim Demaille <[EMAIL PROTECTED]> writes:
|> > "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
|>
|> Andreas> Or maybe this limit should be increased by default?
|>
|> Yep, it sounds very reasonable.
|>
|> What would you suggest? Jump to say 1024?
Well, pick any magic number you
> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
|> What would you suggest? Jump to say 1024?
Andreas> Well, pick any magic number you like. Are there any other
Andreas> loops in the autoconf macros that may hit this limit?
Well, yes and no. Yep, there are others, but they are a
Akim Demaille <[EMAIL PROTECTED]> writes:
|> BTW, you might want to use several AC_CONFIG_FILES. Using a single
|> huge AC_OUTPUT seems bizarre to me.
That does not help, since AC_CONFIG_FILES just collects the files. They
are actually processed by AC_OUTPUT.
Andreas.
--
Andreas Schwab
| Akim Demaille <[EMAIL PROTECTED]> writes:
| |> BTW, you might want to use several AC_CONFIG_FILES. Using a single
| |> huge AC_OUTPUT seems bizarre to me.
|
| That does not help, since AC_CONFIG_FILES just collects the files. They
| are actually processed by AC_OUTPUT.
Hm... but IIRC there
Akim Demaille <[EMAIL PROTECTED]> writes:
|> | Akim Demaille <[EMAIL PROTECTED]> writes:
|> | |> BTW, you might want to use several AC_CONFIG_FILES. Using a single
|> | |> huge AC_OUTPUT seems bizarre to me.
|> |
|> | That does not help, since AC_CONFIG_FILES just collects the files. They
|> |
This came up on the gnupg-user mailing list. While it is not per se
an autoconf problem, I should think that autoconf must provide some
workarounds to work under MacOS X. Or is it a matter of configuring
zsh differently? The failing line of code quote below is quite common.
> >>The line
> >>
IMHO, _AC_CHECK_TYPE_REPLACEMENT_TYPE_P should treat words of the form
[a-z]*_t as types so that AC_CHECK_TYPE(__u8, u_int8_t) does the right
thing. Incidentally, AC_CHECK_TYPE(__s8, int8_t) is already treated as an
old form, because int8_t starts with "int".
Andreas.
--
Andreas Schwab
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:
Lars> This came up on the gnupg-user mailing list. While it is not
Lars> per se an autoconf problem, I should think that autoconf must
Lars> provide some workarounds to work under MacOS X. Or is it a
Lars> matter of configuring zsh differe
I'm willing to release 2.51 more or less this weekend. There are
still some open bugs, some of which I'm going to kill tomorrow (only
the trivial ones). Others require more adventurous patches, and are
delayed to 2.52 or later.
If you know regressions between 2.50 and 2.50a, please let us know
Hi, Paul!
Sorry I didn't review your patch before applying, but I'm running the
testsuite every day, and it immediately spotted a failure caused by your
patch.
AC_SYS_RESTARTABLE_SYSCALLS now issues a warning, but it's defined with
AC_DEFUN, not AU_DEFUN. Therefore, tests/mktests.sh doesn't cons
Hi!
Since the discussion stopped, can we agree on the following patch? Feel free
to add more documentation on fork() vs vfork() later.
2001-06-15 Rüdiger Kuhlmann <[EMAIL PROTECTED]>
* acfunctions.m4: (AC_FUNC_VFORK) renamed to _AC_FUNC_VFORK. Remove
AC_DEFINEs and don't gue
> Date: Fri, 15 Jun 2001 15:13:49 -0400 (EDT)
> From: Pavel Roskin <[EMAIL PROTECTED]>
>
> Either I'm missing something obvious or the current scheme with AU_DEFUN
> should be reworked.
You're not missing anything obvious that I can see, unfortunately.
> +If @file{vfork.h} is found, define @code{HAVE_VFORK_H}. If a working
> +@code{vfork} is found, define @code{HAVE_WORKING_VFORK}. Otherwise,
> +define @code{vfork} to be @code{fork} for backward compatibility.
You need to append "with previous versions of @command{autoconf}" here.
> +In case
19 matches
Mail list logo
