Re: stdbool macro, take 2

> So AC_HEADER_STDBOOL should remove any preexisting stdbool.h before > doing any tests that depend on stdbool.h. Fixed. > I don't see why this would be needed. `make distclean' can just > remove stdbool.h unconditionally. Right. > Can't you use ac_cv_header_stdbool_h for this purpose? ac_cv

[RFC] shtool

I've recently submitted a patch to automake so that it can use shtool instead of the mkinstalldirs, mdate and install shell scripts. However, I think that for shtool support to be complete we need to support it in autoreconf as well, which I volunteer to do. To this end, I would propose a macro

Re: [RFC] shtool

> > I've recently submitted a patch to automake so that it can use shtool > > instead of the mkinstalldirs, mdate and install shell scripts. > > Can you please give us a URL for that patch? The patch can be found on the automake-patches list http://mail.gnu.org/pipermail/automake-patches/2002-Ju

Re: [RFC] Multi-processor friendly autoconf?

> How will you write config.status and config.log in a serial manner? Use a > bunch of little files and assemble them at the end? If the configure > script aborts with an error, where will the user find the diagnostic > information? Maybe with trap? Remember that there is still a configure she

Libtool 1.4.3

ing for libtool 1.4.2 at [EMAIL PROTECTED], CCing [EMAIL PROTECTED] . Paolo Bonzini

Re: Libtool 1.4.3

> The community are the maintainers, therefore a maintainer has spoken for > a minor version increment, rather than a patch release increment. Do you mean a minor version increment starting from branch-1_4 or from HEAD? Paolo

Re: configure.lineno?

> The configure scripts generated by the newest versions of Autoconf > leave a configure.lineno file sitting around after running the > configure script. Is this intentional? First of all, I knew about this behavioral change (and it was also pointed out by Akim on the patches mailing list, but co

heads up -- releasing sed 4.0e using autoconf 2.59a

Hi everybody, I just placed on ftp://alpha.gnu.org/gnu/sed/sed-4.0e.tar.gz a beta release of sed that uses CVS autoconf. Hopefully this will provide some helpful information. Paolo

Re: Is there a way to insert a short pause?

On 10/15/2009 08:29 PM, Ralf Wildenhues wrote: That, on the other hand, sounds like an interesting idea. We could easily let configure print something like configure: WARNING: There have been warnings during this configure run. when it has come across a AC_MSG_WARNING. WDYT? Interesting i

Re: Is there a way to insert a short pause?

On 10/16/2009 11:38 PM, Richard Ash wrote: ^configure: [0-9].: WARNING: might do it (until we find what grep is and isn't capable of on different platforms). No, until someone renames configure. :-) Paolo ___ Autoconf mailing list Autoconf@gnu.org

Re: AC_TRY_COMPILE() annoyances with 2.63b

simple example: $ cat configure.ac AC_INIT AS_IF([:], [ : some random user stuff ],[ AC_PROG_LEX AC_DECL_YYTEXT ]) AC_OUTPUT $ autoconf --version autoconf (GNU Autoconf) 2.64 $ autoconf&& ./configure -q ./configure: line 2676: syntax error near unexpected token `fi' ./co

Re: AC_CONFIG_HEADERS & AC_CONFIG_FILES combo

On 10/16/2009 05:49 PM, Sam Steingold wrote: I have a header file avcall.h which collects the results of autoconf tests, so it is mentioned in AC_CONFIG_HEADERS. I also want it to define the package version cpp macro, so I added #if !defined(LIBFFCALL_VERSION) # define LIBFFCALL_VERSION @PACKAGE

Time for a new release?

The last weeks have been calm and the "autoconf: AC_TYPE_INT32_T generates broken test?" bug is particularly serious. What about a new release as soon as the pending documentation fixes are resolved. And what about calling it 3.0? :-) Paolo ___ A

Re: AC_CHECK_FUNC is not compatible with gcc -Werror

On 01/22/2010 02:35 AM, Eric Blake wrote: It would be even slicker to do this without having to recompile (that is, rewrite AC_LANG_FUNC_LINK_TRY to use the new logic, rather than making AC_CHECK_FUNC call AC_LINK_IFELSE twice). Since typeof(__builtin_strfry) gives an error, you'd then have two

Re: AC_CHECK_DECLS(basename) (Was: Re: Ping: patches required for --enable-build-with-cxx)

I'm adding autoconf@gnu.org to the destinations, since this is a pretty fundamental problem with AC_CHECK_DECL and C++ On Tue, Feb 9, 2010 at 02:17, Joern Rennecke wrote: > >> On 02/08/2010 09:58 AM, Joern Rennecke wrote: >>> >>> That would only work if every program that uses libiberty uses >>>

Re: AC_CHECK_DECLS(basename) (Was: Re: Ping: patches required for --enable-build-with-cxx)

On 02/17/2010 04:41 PM, Joern Rennecke wrote: Quoting Ralf Wildenhues : sed alternation \| is not portable. I've replaced it now with a pair of substitutions. I also fixed the ',' substitution to give yield on opening bracket for the next cast, and to apply for all commas. + $[]as_decl_type

Re: AC_CHECK_DECLS(basename) (Was: Re: Ping: patches required for --enable-build-with-cxx)

>> Maybe we can use this in AC_CHECK_DECLS instead of having a new >> separate macro.  If there is a parenthesis in the name call the new >> version, if there is none, call the old one. > > You shouldn't need to keep the old version around, it's supposed to be > a drop-in replacement.  The reason I

Re: Use resolution file, autoconf help needed

On 10/26/2010 07:53 PM, Ralf Wildenhues wrote: I already wrote on the bug-autoconf list that this has been fixed in upstream Autoconf 2.60 already. I looked more closely now. The problem is purely libiberty-specific. It still has an old hunk overriding AC_LANG_FUNC_LINK_TRY(C) in libiberty/aclo

Re: autotest: problem testing daemons, with possible fix

On 11/26/2010 10:23 AM, Paul Eggert wrote: On 11/25/2010 03:24 PM, Luke Mewburn wrote: Your patch also solves the problem. OK, thanks, I installed it. Still would appreciate another pair of eyes at some point. I think it's good. Paolo ___ Autoco

Re: [Help-smalltalk] [PATCH] build: drop useless AC_SUBST of 'INCLUDES'

Il 11/01/2013 11:28, Stefano Lattarini ha scritto: > * snprintfv/configure.ac: Here. Not only that substitution was useless, > but it was causing runtime warnings with Automake 1.13, and, since > support for $(INCLUDES) is bound to disappear in Automake 1.14 (in favour > of $(AM_CPPFLAGS)), it wil

Making _AC_COMPUTE_INT public?

Is anybody against renaming _AC_COMPUTE_INT to AC_COMPUTE_INT, and documenting it? GCC needs it to find the alignment of types at configure time (see the patch attached to http://gcc.gnu.org/PR25884) and it seems that it could be useful in general. If nobody objects, I'll prepare the patch.

[PATCH] Make AC_COMPUTE_INT public

after Autoconf-2.60... Then you will hate me for this patch, which I promised to send at http://lists.gnu.org/archive/html/autoconf/2006-01/msg00110.html (yes, five months ago). It makes AC_COMPUTE_INT public. Regtests in progress, tested already with `make info'. Paolo

read-only $ac_executable_extensions

The variable $ac_executable_extensions is never written to, and only used in loops of the form: for ac_exec_ext in '' $ac_executable_extensions; do ... done Can we zap it? Paolo ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mail

Re: read-only $ac_executable_extensions

AFAIK it has been introduced and is used by users as workaround (e.g., by setting it in config.site). So if we can agree to it, we should probably document it rather than zapping it. See for example . Or we could steal code to set it app

more test failures

I'm seeing these tests failing: 70 72 73 74 75 76 77 78 79 80 81 82 83 84 85 90 I committed my patches anyway after making sure they were preexisting, but someone should look at them... be careful, please. Paolo ___ Autoconf mailing list Autoconf

Re: more test failures

be an m4 problem? Let's start with the md5sum of testsuite: 41edcfeffee5f2c2f913f8f780d1dda1 testsuite I put it at http://www.inf.unisi.ch/phd/bonzini/testsuite.bz2 My m4 is GNU M4 1.4.8 Copyright (C) 2006 Free Software Foundation, I

Re: more test failures

... but with M4 1.4.10. So I think we can rule out an m4 bug for generating the testsuite correctly. Perhaps you are tripping over a shell bug? I tested with bash 3.2.25. Indeed mine is 2.05b. Paolo ___ Autoconf mailing list Autoconf@gnu.org ht

Re: Autotest function usage

> cat >"$at_test_source"-AT_ordinal <<_AT_T_EOF ... _AT_T_EOF and source the goo by the shell again. I don't know of another portable tool that can write to arbitrarily many files. Me neither. Does not seem "too" disgusting. Paolo ___ Autoconf

Re: Detecting that AC_PROG_LIBTOOL has been invoked

m4_define([m4_provided], [ m4_provide_if([AC_PROG_LIBTOOL], [], [ m4_provide_if([LT_INIT], [], [m4_warn([syntax], [Libtool required by $1])])])])]) ... m4_provided([MY_MACRO_NAME]) I didn't count the number of closing brackets. What is the m4_provide_if? I didn't find it in

Re: default $(libdir) and bi-arch systems

> How about changing the libdir default (currently $exec_prefix/lib) to be > $exec_prefix/lib64 or $exec_prefix/lib/64, respectively, when > - not cross-compiling, and > - $CC $CPPFLAGS generates 64-bit mode object files, and > - 64-bit mode object files are installed in /usr/lib64 or /usr/l

Re: default $(libdir) and bi-arch systems

> Some care needs to be taken, though, because the gcc compiler on MacOS X 10.5 > (which produces 32-bit code by default) is configured like this: > > $ gcc -print-multi-os-directory > . > $ gcc -print-multi-os-directory -m64 > x86_64 > $ gcc -print-multi-os-directory -m32 > . > $ gcc -print-mult

Re: libraries of shell script functions

Bruno Haible wrote: > Paolo Bonzini wrote: >> For now, I think Peter's select function could go in m4sh. m4 is the >> linker, then. > > How does one use "m4 as the linker"? Where is this documented? You write your script in m4sh, not in pure Bourne shell.

[RFH] zsh shell function portability issue

You will remember the shell function portability issue in zsh... Do you think that these functions: ac_func_c_try_compile() { rm -f conftest.$ac_objext if { (ac_try="$ac_compile" case "(($ac_try" in *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; *) ac_try_echo=$ac_try;; esac eval ac_try_echo=

Re: [RFH] zsh shell function portability issue

Ralf Wildenhues wrote: > * Paolo Bonzini wrote on Mon, Oct 13, 2008 at 11:59:22AM CEST: >> You will remember the shell function portability issue in zsh... > > Yes; sigh. > >> Do you think that these functions: [...] >> are portable? (Yeah, the code is totally u

Re: Extracting configuration info from config.status

Brian Dessent wrote: > Barry Leslie wrote: > >> It would be really useful if there was a configure option that would allow >> you to point to another location and tell configure to get it's settings >> from there. > > If you just want to get the content of variables from a foreign build > dir you

How to use m4_require with arguments?

(Note: I wanted use this to provide different implementations of AC_COMPILE_IFELSE for different languages. I think I can also do without it, but I thought I'd write nevertheless about a more general m4sugar problem). The m4sugar.m4 file mentions the possibility to use: m4_require([AC_CHECK_H

Re: How to use m4_require with arguments?

>> 1) that this requires a contract between the macros: if the definition >> uses m4_provide([$0($@)]), the caller should use m4_require_with_args; >> otherwise, it should use m4_require. > > Perhaps we could redefine m4_require to always supply () (equivalent to 1 > empty argument) ... And m4_d

[CFT] Shell functionization patch (if you don't know what that means, it's faster Autoconf and leaner configure scripts)

ipts is more-or-less unchanged, though I expect that the more readable code of configure scripts will help in the medium term squeezing some percentage out of that too. Testsuite passes. Paolo 2008-10-16 Paolo Bonzini <[EMAIL PROTECTED]> * lib/autoconf/header

Re: [CFT] Shell functionization patch (if you don't know what that means, it's faster Autoconf and leaner configure scripts)

> What do you think? Agreed on everything. BTW, I think it's best for your sanity if you wait for the 12 separate patches. :-) This is just a call for test; the basic idea won't change even if the implementation details of the shell functions (and not of the calls) change, so it is safe to do it

Re: [RFH] zsh shell function portability issue

>> Do you think that: >> >> (eval "$ac_link") 2>&5 >> ac_status=$? >> (eval "$ac_try") 2>&5 >> ac_status=$? >> >> >> are portable? > > Pretty likely not: > > $ zsh --version > zsh 4.2.3 (powerpc-apple-darwin8.0) > $ zsh > $ f () { ( exit 1); echo $?; }; f > 0 > $ f ()

Re: [CFT] Shell functionization patch (if you don't know what that means, it's faster Autoconf and leaner configure scripts)

>> Also, the zsh issue has to be understood better (and could be a deal >> breaker, though I don't think so). > > It basically means that you cannot call exit nor trap inside a shell > function. Nor can you use $? at the start of a function. But you'll > deal with that anyway since you will wan

Re: cache problem

> I recently posted a patch to do just this. It wasn't applied, one > reason being that we didn't see a way how two configure scripts could be > running simultaneously; with AC_CONFIG_SUBDIRS at least (the GCC tree > uses a different way but uses per-configure cache files). How do you > get two

Re: [RFH] zsh shell function portability issue

> Right. Might want to explicitly discourage touching those variables. > (This is hopefully not common today, but probably not so uncommon in > legacy code.) I'll look at http://www.google.com/codesearch?q=ac_(compile|link|cpp)%3D+file%3Aconfigure.ac http://www.google.com/codesearch?q=ac_(compi

Re: [RFH] zsh shell function portability issue

Paolo Bonzini wrote: >> Right. Might want to explicitly discourage touching those variables. >> (This is hopefully not common today, but probably not so uncommon in >> legacy code.) > > I'll look at > > http://www.google.com/codesearch?q=ac_(compile|link

Re: [CFT] Shell functionization patch (if you don't know what that means, it's faster Autoconf and leaner configure scripts)

Eric Blake wrote: > According to Paolo Bonzini on 10/16/2008 10:38 AM: >> Hi all, this is *the* patch to add shell functions to Autoconf at last. > >> I am submitting it in one piece for testing, but I'm not really calling >> for review; for that, I'll submit it

Re: use of AC_TRY_EVAL broken

Eric Blake wrote: > The following gnulib files use an undocumented autoconf macro AC_TRY_EVAL, > which is buggy because it does not prevent against shell glob expansion > and could end up invoking arbitrary commands according to the contents of > the current directory. We need to switch these over

Re: question about AC_SEARCH_LIBS

Vincent Torri wrote: > > Hey, > > according to the documentation, AC_SEARCH_LIBS searches a function name > in a set of libraries and add to LIBS the library that contains the > function (if any). > > If I have that code: > > AC_SEARCH_LIBS([fnmatch], [fnmatch iberty evil], [res="yes"], [res="n

m4_text_box => AS_TEXT_BOX?

m4_text_box is the sole user of quadrigraphs in m4sugar.m4. Together with m4_warn, in turn, it is the sole feature needing autom4te. I don't care about m4_warn very much, but it would be nice to rename m4_text_box to AS_TEXT_BOX and move it to m4sh. Bison does not use it, and Google says it is u

Re: m4_text_box => AS_TEXT_BOX?

Eric Blake wrote: > Paolo Bonzini gnu.org> writes: > >> m4_text_box is the sole user of quadrigraphs in m4sugar.m4. > > Nope. m4_text_wrap also uses it. m4_text_wrap knows about quadrigraphs (via m4_qlen), but does not emit them. If the input has no quadrigrap

Re: m4_text_box => AS_TEXT_BOX?

> But you want to divide it out: > > m4sugar (no quadrigraph support) > autom4te (quadrigraphs, warnings) > m4sh (shell functionality) > other layers More precisely: m4sugar (cool stuff, supporting but not needing quadrigraphs) autom4te (quadrigraphs, warnings) m4sh (shell functionality) other

Re: [CFT] Shell functionization patch (if you don't know what that means, it's faster Autoconf and leaner configure scripts)

>> Perl is also quite rapidly losing popularity to other scripting languages >> such as Python and Ruby. There was an over five year span without a Perl > > Popularity shouldn't be a metric here, in that case sh would would lose, too. Not really, sh is not going to be replaced for system tasks,

Re: Disable the present-but-cannot-be-compiled header warning?

Jeff Squyres wrote: > Is there a way to disable the present-but-cannot-be-compiled header > warning from AC_CHECK_HEADERS in AC 2.61? I don't see any mention of > disabling this warning in either the "Header Present But Cannot Be > Compiled" or "Generic Header Checks" sections in the 2.61 docs. >

Re: [CFT] Shell functionization patch (if you don't know what that means, it's faster Autoconf and leaner configure scripts)

>> Nothing prevents a configure script (written in sh) from using scraps of >> Perl. Hopefully the script would check that Perl exists before actually >> using it. > > But is there a clean way without having to watch the m4 special > characters, etc., i.e., some kind of escape so we can change t

Rejecting dash because it lacks +=?

I wanted to see if /bin/dash was really that much faster (*), and found several problems. Some of them I can send patches for; some are in libtool which should really ditch its poor-man echo replacement; one is worth discussing here. The problem is that /bin/dash did not pass the "suggested" test

Re: Rejecting dash because it lacks +=?

> POSIX requires $LINENO (dash is buggy for not providing it). It is. > I'm committing this: Looks nice. Paolo ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: Disable the present-but-cannot-be-compiled header warning?

> No warning that, since the aim was to move away from the old semantics > to the new semantics, using `-' gets the user stuck with the old > semantics which means he will put stones in the way of the intended > move? I think we need a better warning in the manual that [-] is not something to be a

Re: Disable the present-but-cannot-be-compiled header warning?

Jeff Squyres wrote: > On Oct 31, 2008, at 3:30 AM, Paolo Bonzini wrote: > >> I didn't understand really what was Jeff's usecase. > > In short: all we want is a simple "no" result from the test. > >

Re: Disable the present-but-cannot-be-compiled header warning?

ure it's the right thing to do, it's surely the most conservative. Paolo commit 852e48d74126ca0ad43efb41a4e4d7a7d3eabd8b Author: Paolo Bonzini <[EMAIL PROTECTED]> Date: Fri Oct 31 16:53:17 2008 +0100 Finish AC_CHECK_HEADERS transition. * NEWS: Document change. * doc/autoconf.texi (Present But C

Re: Disable the present-but-cannot-be-compiled header warning?

> I think we're all in agreement on this point - it's time to favor the > compile check. Yes, but we have to agree on how. :-) > I think the warning is still handy - there are too many instances of > headers that need prerequisites (think , whose man > page mentions that must be included first;

Re: Define a complete rule via autoconf (quoting issue, AC_SUBST)

> I get errors running ./configure. I guess, this is, because of a problem > with the quotation. Doing a simple: > > AC_SUBST([DESKTOP_DATA_RULE], [ > target: requirements > @list=... > > ]) DESKTOP_DATA_RULE="AS_ESCAPE([ ... ])" AC_SUBST([DESKTOP_DATA_RULE]) should work. Paolo __

some numbers

On GNU Smalltalk with M4 1.4.8: 2.6110.0sec 1037568 bytes 2.627.0sec 1057356 bytes 2.637.5sec 1058211 bytes 2.63+funcs 6.0sec 742044 bytes git 4.6sec 744144 bytes Not to mention that system time went up from ~7% to 12-

Re: Problem with AC_DEFINE in autoconf 2.59

> if test "x$release_mode" = "xyes" ; then > AC_DEFINE([my_debug(s, ...)],[], [Disable my_debug calls]) > else > AC_DEFINE([my_debug(s, ...)],[g_debug(s, ##__VA_ARGS__)], [Enable > my_debug calls]) > fi > > The problem is that using autoconf 2.59, the previous code will generate > in config.h:

Re: some numbers

>> 2.61 10.0sec 1037568 bytes >> 2.62 7.0sec 1057356 bytes >> 2.63 7.5sec 1058211 bytes >> 2.63+funcs 6.0sec742044 bytes >> git 4.6sec 744144 bytes >> > > Yes, it is! Could you denote whether that is autoconf run time or > configure r

Re: [PATCH 6/6] use print or printf or cat as $ECHO

were past the detect-better-shell test, but that was too heavy when the shell was not good enough. To fix that you could rewrite _AS_RUN to use here documents, and change the remaining uses of AS_ECHO in error messages to cat. Then you don't need at all anymore _AS_ECHO_PREPARE in _AS_SH

Re: [PATCH 6/6] use print or printf or cat as $ECHO

> Who guarantees you that ksh supplies TMOUT? OTOH, TMOUT is not in any > way restricted, so a user (more likely: a sysadmin) could set and export > it, and reasonably so: every Posix shell understands it, bash included. I tested that both ksh and pdksh set TMOUT = 0 at startup, for example:

Re: m4_version_prereq

Eric Blake wrote: > According to Eric Blake on 12/18/2008 6:06 AM: >> According to Bruno Haible on 12/18/2008 3:44 AM: m4_version_prereq([2.60],, [ It works at least back to Autoconf 2.59. >>> Thanks for the hint. But m4_version_prereq is undocumented (as already >>> mentioned >>>

Re: _AC_CHECK_HEADER_OLD

Did you try implementing a fourth argument to AU_DEFUN yet? Yes of course. But the problem is that the argument of m4_defn is autoupdated too. Let me know. Paolo

'set +o' or '. /dev/fd/0' or?...

Hi autoguys, I am piping the output of a script to the shell, and using COMMAND | sh would not respect the -e/-x settings of the outer shell. I have thought of two replacements: { set +o; COMMAND; } | sh COMMAND | . /dev/fd/0 The second looks nicer, but it's not portable. Actually I

Re: 'set +o' or '. /dev/fd/0' or?...

On 07/13/2009 01:26 PM, Eric Blake wrote: { echo "set -$-"; COMMAND; } | sh This does it, yes. (You've been using too many fifos for the parallel autotest :-). Paolo ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/

AH_CHECK_HEADERS

You never heard of it, right? Me neither until today, but KDE 3.5.10 uses it. https://bugs.gentoo.org/attachment.cgi?id=199443&action=view Do we want to add it back and release 2.64.1 in a couple of weeks? Paolo ___ Autoconf mailing list Autoconf@

Re: AH_CHECK_HEADERS

Do we want to add it back and release 2.64.1 in a couple of weeks? Are you volunteering (to write and test the patch)? Yes, of course. Paolo ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

[PATCH] Clarify comparison of echo, printf, and AS_ECHO*.

e is what I committed. ChangeLog |8 doc/autoconf.texi | 28 ++-- 2 files changed, 26 insertions(+), 10 deletions(-) diff --git a/ChangeLog b/ChangeLog index 9011143..1e22e63 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2009-07-30 Paolo Bonzini

Re: AC_INIT seems to be setting CXXFLAGS

The terrible part about how this mechanism works is that it injects into CXXFLAGS itself, which means that, without my configure script can't override that via the setting of AM_CXXFLAGS. I cannot parse this sentence. Can you explain? Paolo ___ A

Re: AC_INIT seems to be setting CXXFLAGS

Actually, it's that I can't override these in a default build by any mechanism other than editing CXXFLAGS, which is listed as something that autoconf scripts are not to do. The intended meaning of "are not to do" is that the user should always be able to override CFLAGS and CXXFLAGS. In other

Re: "The `-a', `-o', `(', and `)' operands are not portable": please clarify

On 08/07/2009 04:31 PM, Paolo Bonzini wrote: Maybe it's worth a ping to the dash maintainers... Yes... Is that a "yes I'll do it"? I'm happy to otherwise, pointing them at this thread, but I imagine it would have more effect from an autoconf maintainer. Which I a

Re: toplevel configure hits sed program length limit on HP-UX

On 08/31/2009 08:54 PM, Ralf Wildenhues wrote: While still working to prove Bob wrong on the fixincludes sed issues, Bob? - require a better sed, - split the script in two inside Autoconf (if $extrasub is nonempty), - allow for extra sed scripts here. Like a new variable $ac_presub, that is

Re: toplevel configure hits sed program length limit on HP-UX

In fact, I think this API shouldn't be even more encouraged. It doesn't really fix things in an elegant way, and it doesn't help for other pending issues in the GCC tree (such as the multilib fixups that aren't applied in all cases; report coming up). I agree. However, I did not have any alter

Re: toplevel configure hits sed program length limit on HP-UX

On 08/31/2009 10:41 PM, Ralf Wildenhues wrote: * Paolo Bonzini wrote on Mon, Aug 31, 2009 at 10:00:01PM CEST: In fact, I think this API shouldn't be even more encouraged. It doesn't really fix things in an elegant way, and it doesn't help for other pending issues in the GCC tr

Re: multilib and Makefile regeneration

On 08/31/2009 11:11 PM, Ralf Wildenhues wrote: The easiest for now would be (3), the coolest, most difficult and probably most dangerous one would be (2). Something like AC_CONFIG_FILES_COMMANDS(some/Makefile, more-user-commands, [more-init-cmds]) but then the ord

Re: iterating over arguments

On 09/14/2009 03:11 PM, Eric Blake wrote: Actually, I only found one existing clients that needed changing due to returning a quoted string; and it specifically WANTED the quoting I agree with the change, the m4_dquote was probably added there only as a result of using Autotest to test m4sugar

Releasing 2.65?

It's been pretty calm lately. The only bugs reported are related to parallel testsuites. So, what about releasing 2.65? Paolo ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

A small test case for the AC_CONFIG_xxx problem

Here is a test case for the problem I reported this morning on autoconf-patches. Run autoconf and configure on the script at the end of the message, then try the following config.status invocations ./config.status test2 gives an error because test2 it is not even matched: in config.status

Re: A small test case for the AC_CONFIG_xxx problem

| echo > test1 | testsrc=test1 | testdest=test2 | AC_CONFIG_LINKS($testdest:test1 test3:$testsrc, [], | [testsrc=$testsrc |testdest=$testdest]) > I.e., test3 is OK, but not test1. There are two parts in it. One bug is this controversial use of AC_CONFIG_LINKS, which I only introduced for

Macro to test for stdbool.h

Here is a macro to test for stdbool.h; since it is a standard header I think it belongs in autoconf rather than in some macro archive. The patch is against 2.52f Paolo diff -r -U3 old/doc/autoconf.texi new/doc/autoconf.texi --- old/doc/autoconf.texi Fri Nov 2 17:10:56 2001 +++ new/doc

stdbool macro, take 2

ac_stdbool_h). STDBOOL_H is substituted and passed through the INIT-CMDS, and also used by config.status to decide whether to create stdbool.h. Here is the patch from 2.52f (no MIME this time :-) and a ChangeLog entry 2001-11-08 Paolo Bonzini <[EMAIL PROTECTED]) * doc/autoconf.texi: docu

[RFC] Multi-processor friendly autoconf?

Here is an idea for writing a multiprocessor-friendly autoconf. Basically, the idea is to change the configure phase into a Makefile target, and use caching as a way to split it into various sub-targets that can be executed in parallel. The shell script might run the "sane build" test and then sp

Re: Libtool 1.4.3

> There is one big question which must be answered first: will it have > to be Autoconf 2.13 compatible? > > I *strongly* suggest that it must not. In fact the only change that I made so far that is not in Debian is autoupdating it. Paolo

Re: Libtool 1.4.3

> Wouldn't it be better to get libtool 1.5 out the door? The resources > required to achieve a releasable product are similar and CVS libtool > already contains most of the fixes that would go into a 1.4.3. But it also contains more features. Releasing 1.5 should be done by the maintainers, not

Providing library functions as part of autoconfiscation

Akim suggested recently on bison-patches that autoconf include several possible replacement functions and that as part of autoconfiscating a package the files would be added to it (another part of the suggestion was to have the program specify its license and only include files that were compatibl

libtool incompatible with current autoconf

You can autoupdate libltdl safely. You can also extract it from a GNU Smalltalk tarball, for example: ftp://alpha.gnu.org/gnu/smalltalk/smalltalk-2.0.11.tar.gz -- |_ _ _ __ |_)(_)| ),' `-'

Re: [Bug-gnulib] addition: size_max.m4, ptrdiff_max.m4

> For example, you repeat the following sed on it until it > doesn't change any more: > > [snip] You can use the t command to avoid looping. However, while indeed a bit of a hassle, doing arithmetic with sed is not so hard... You can use 10 commands to sum two numbers: http://sed.sourceforge.net/

sed 4.0e (built with autoconf 2.59a) works on 45 platforms

A user was able to compile sed 4.0e on forty-odd platforms, including alphas and sparcs with their native compilers. As you may recall, I released it with an autoconf 2.59a-generated configure script. That's good news. What's still remaining for autoconf 2.60 to reach beta stage? Paolo

Re: sed 4.0e (built with autoconf 2.59a) works on 45 platforms

> > What's still remaining for autoconf 2.60 to reach beta stage? > > I don't know of any showstopper bugs. Actually I know of something that looks like a bug to me. It's been there forever and is something that I don't have an explanation for. When cross-compiling, autoconf accepts a bare name

Re: sed 4.0e (built with autoconf 2.59a) works on 45 platforms

> > A user was able to compile sed 4.0e on forty-odd platforms, including alphas > > forty-odd flavors of Linux? Of course not since I mentioned the Digital and Sun native compilers (and shells). Do you say this because you have negative reports compiling sed 4.0e on some odd platforms? Paolo

Re: sed 4.0e (built with autoconf 2.59a) works on 45 platforms

> > > When cross-compiling, autoconf accepts a bare name for a tool > > > (e.g. "ld" for a cross-linker); gcc has special macros to exclude > > > cross tools without a prefix. Is there a reason to do so? > > > > I assume so, but I don't know what it is. > > Canadian Cross building support. Of cou