Re: config.cache considered harmful

I very much like the bug report quoted below, and I suggest that it be put into the autoconf source code somewhere, either next to the code that generates config.cache, or perhaps into a new section of documentation that discusses autoconf portability issues. It would also be helpful to put the U

Re: AC_CHECK_TYPE search locations

From: Akim Demaille <[EMAIL PROTECTED]> Date: 25 Feb 2000 09:42:08 +0100 So, do you think I should add inttypes.h? Perhaps eventually, but I suspect that it's premature to do it now. Part of the problem is that STDC_HEADERS is currently specific to ANSI C (1989); it hasn't been moderni

Re: autoconf --trace

From: Akim Demaille <[EMAIL PROTECTED]> Date: 14 Feb 2000 10:43:04 +0100 s/^m4trace:\([^:]*\):\([^:]*\): -[0-9]*- \([^(]*(\)\(.*\)$/\3[\1], [\2], \4/ This looks like a good idea to me. I would improve it slightly by making it more specific, e.g. s/^m4trace:\([^:][^:]*\):\([0-9][0-9]*

Re: autoconf bug on UnixWare 7.1.0

Date: Tue, 15 Feb 2000 21:13:22 +1100 (EST) From: Ben Elliston <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] >+uname -m = `(uname -m) 2>/dev/null || echo unknown` >+uname -

Re: AC_CHECK_TYPE search locations

From: Akim Demaille <[EMAIL PROTECTED]> Date: 24 Feb 2000 17:42:41 +0100 should we put stdint.h or inttypes.h into the default includes? inttypes.h. ISO C 1999 says that inttypes.h includes stdint.h, so there's no need to include stdint.h separately in a standard environment. Many imp

Re: xemacs configure script doesn't have AC_DEFINE

Date: Sun, 27 Feb 2000 02:27:56 -0800 (PST) From: Martin Buchholz <[EMAIL PROTECTED]> I know of no way to quote a non-paired quote character In the current autoconf draft, @BKL@ and @BKR@ expand to left and right brackets; that should get you want you want. (Those names should get chan

Re: @BKL@, @BKR@, etc.

From: Akim Demaille <[EMAIL PROTECTED]> Date: 28 Feb 2000 09:16:00 +0100 I'm very OK with changing them. I buy any suggestion of names. Currently there are four guys: s/@BKL@/[/g s/@BKR@/]/g s/@DLR@/$/g s/@PND@/#/g Here's an idea: why don't we bo

Re: @BKL@, @BKR@, etc.

From: Akim Demaille <[EMAIL PROTECTED]> Date: 28 Feb 2000 18:16:13 +0100 Paul> s/@<:@/[/g s/@:>@/]/g s/@S|@/$/g s/@%:@/#/g Can we consider these guys are unlikely enough to avoid using @@? No. E.g. grep's configure.in says: LIBOBJS=`echo $LIBOBJS|sed 's/\.o /\$U.o /g;s/\.o

Re: Fix some tests to be g++ >= 2.95 safe

From: Akim Demaille <[EMAIL PROTECTED]> Date: 06 Mar 2000 10:07:37 +0100 I would not condition the includes by __cplusplus, since the C compiler will be happy too to have them. What do other people think? I agree with you. Also, ifdef and ifndef are banished from Autoconf, use o

Re: sys/stat.h

From: Akim Demaille <[EMAIL PROTECTED]> Date: 15 Mar 2000 09:44:55 +0100 Akim> sys/stat.h: Portable or not? Paul> I think it's portable to all targets of interest to GNU applications. OK, thanks. Shall we include it in the set of default includes? There is a bit of a slippery

Re: Standard macro for OpenGL check?

From: Jim Meyering <[EMAIL PROTECTED]> Date: 13 Mar 2000 23:55:52 +0100 FYI, even indented, `#error' is not portable. SunOS 4.1.4 cc rejects it. Hmm, that doesn't match my recollection. I just checked, and SunOS 4.1.4 cc compiles and runs the following program just fine: #if 0 #er

Re: Standard macro for OpenGL check?

From: Jim Meyering <[EMAIL PROTECTED]> Date: 14 Mar 2000 09:16:08 +0100 I didn't test it, but rather based it on a fileutils ChangeLog entry from you. Maybe you were using a different version of cc back when you wrote it? No, it's the same cc. Russ Allbery had the right analysis

Re: sys/stat.h

From: Akim Demaille <[EMAIL PROTECTED]> Date: 14 Mar 2000 11:03:13 +0100 Portable or not? I think it's portable to all targets of interest to GNU applications. Many GNU applications include without checking for its inclusion. has been supported by every Unix-like system for over two

Re: Security issues and mktemp

From: Akim Demaille <[EMAIL PROTECTED]> Date: 27 Mar 2000 17:25:20 +0200 my proposal is to support `mktemp -d', and only `mktemp -d', no juggling with mktemp for each file. If the system on which Autoconf runs does not support `mktemp -d', then (umask 077 && mkdir $$). That so

Re: Detecting compiler vendor

Date: Tue, 4 Apr 2000 16:34:04 +0200 (MET DST) From: Peter Eisentraut <[EMAIL PROTECTED]> What I would like is a general solution that tells me what compiler I'm using so I can add custom options. For example, the project I contribute to needs the option '-Olimit 2000' on OSF/1 for

Re: Performances of awk

From: Akim Demaille <[EMAIL PROTECTED]> Date: 26 Apr 2000 18:41:32 +0200 If you concentrate the measure on this very script, the performance penalty is frightening: It certainly is. This is a performance bug in mawk. I observed the bug in mawk 1.3.3. To work around the problem some

Re: compilation warnings for large file hosts

l bug on some hosts. Here is a patch; it uses _GNU_SOURCE instead of _XOPEN_SOURCE since I think that is better from an autoconf point of view. I'm CC'ing this to the maintainers of autoconf and fileutils as they are using this code too. 2000-05-02 Paul Eggert <[EMAIL PROTECTED]&g

Re: your latest largefile.m4 change induces a warning in regex.c

o safely. I'd also like to fix largefile.m4 so that it didn't depend on $host_os and AC_CANONICAL_HOST, but that's a larger project 2000-05-03 Paul Eggert <[EMAIL PROTECTED]> * m4/largefile.m4 (AC_SYS_LARGEFILE): Define _XOPEN_SOURCE to be 500,

Re: rfc: new libgcc build mechanism

From: Per Bothner <[EMAIL PROTECTED]> Date: 08 May 2000 06:53:13 -0700 I do not see 4.3BSD as a reason to not use functions in shell scripts. I can see good arguments on both sides of this question. A similar question is whether an application should work with K&R C. It used to be tha

Re: acgeneral.m4 & unsupported case patterns

From: Akim Demaille <[EMAIL PROTECTED]> Date: 22 May 2000 10:34:41 +0200 I am not against giving a chance to `[!...]', but it has to be heavily tested. Is there anybody who knows more? I believe negated character ranges were added to /bin/sh around the same time as shell functions.

Re: acgeneral.m4 & unsupported case patterns

From: Akim Demaille <[EMAIL PROTECTED]> Date: 23 May 2000 17:15:16 +0200 expr has a bad reputation Its syntax is awkward -- was that what you were thinking about? But I haven't had portability problems with it, so I don't know what you want to document. Perhaps this is because I uncon

Re: acgeneral.m4 & unsupported case patterns

From: Akim Demaille <[EMAIL PROTECTED]> Date: 23 May 2000 19:13:39 +0200 | if echo "$ac_package" | grep '[[^a-zA-Z0-9_]]' >/dev/null 2>&1; then | AC_MSG_ERROR([invalid package: $ac_package]);; | fi is better, but that's where we come from. The i

Re: acgeneral.m4 & unsupported case patterns

From: Akim Demaille <[EMAIL PROTECTED]> Date: 24 May 2000 10:41:53 +0200 Akim>expr has a bad reputation Paul> Its syntax is awkward -- was that what you were thinking about? Nope, I was referring to the portability. And precisely about the syntax, is `match string expr' p

Re: [gnu.utils.bug] AC_PROG_CC_G, et al, are not very robust

If the file's size is sufficiently small and if the locale is C (which is the case here), you should be able to compute the file's size with this portable script: set X `ls -l "$file"` case "$6" in [0-9]*) size=$6;; *) # We are on a non-POSIX host and the group was omitted, # or t

Re: [gnu.utils.bug] AC_PROG_CC_G, et al, are not very robust

" comment. On Sun, Jun 18, 2000 at 01:44:14PM -0700, Paul Eggert wrote: > set X `ls -l "$file"` > case "$6" in > [0-9]*) > size=$6;; > *) > # We are on a non-POSIX host and the group was omitted, > # or the user overflowed into the group. > size=$5;; > esac

Re: [patch] acgeneral.m4 (dirname usage)

From: Akim Demaille <[EMAIL PROTECTED]> Date: 06 Jul 2000 17:03:52 +0200 echo $dir | sed '/^\/*$/!s,//*$,,;s,[^/]*$,,;s,//*$,/,;/^\/$/!s,/$,,' It's not portable to use "echo". On some hosts, "echo" mishandles backslashes and/or names beginning with "-". It's more portable to use "expr",

Re: [patch] acgeneral.m4 (dirname usage)

From: Bernard Dautrevaux <[EMAIL PROTECTED]> Date: Thu, 6 Jul 2000 17:26:48 +0200 under UN*X, '//1' should give '/', No, under some older flavors of Unix, leading // is a special path name: it refers to a "super-root" and is used to access other machines' files. Leading ///, , etc

Re: [patch] acgeneral.m4 (dirname usage)

From: Akim Demaille <[EMAIL PROTECTED]> Date: 07 Jul 2000 19:53:35 +0200 There is one question though: how sure are you of the portability of this \| construct? I'm pretty sure it was in Unix Version 7. I've been using it for years. The Hylafax administration scripts use it, and th

Re: Autoconf support for bounds checking?

Date: Fri, 21 Jul 2000 11:47:24 -0700 From: Greg McGary <[EMAIL PROTECTED]> It seems to me that the simple solution is teach AC_CHECK_FUNCS (and others?) which library functions have pointers in their signatures, Autoconf shouldn't keep track of which functions have pointers in their

Re: Autoconf support for bounds checking?

From: Greg McGary <[EMAIL PROTECTED]> Date: 21 Jul 2000 13:36:01 -0700 The backward-compatible AC_CHECK_FUNC should also work with BPs as per my second suggestion (try once with return type `char' and again with return type `char *' if `-fbounded-pointers' is in CFLAGS). The check

Re: Autoconf support for bounds checking?

From: Akim Demaille <[EMAIL PROTECTED]> Date: 24 Jul 2000 10:56:01 +0200 What would be the problem with enabling the use of the fourth parameter of AC_CHECK_FUNCS? AC_CHECK_FUNC(func, yes, no, includes)? That sounds right to me. I didn't quite follow your patch, but I assume the ba

Re: Autoconf support for bounds checking?

From: Greg McGary <[EMAIL PROTECTED]> Date: 24 Jul 2000 02:18:59 -0700 > Also, surely trying twice for each function won't work in general. > For example, suppose a library function is available only in > non-bounded-pointers mode, and we are building in bounded-pointers > mode.

Re: LC_COLLATE vs. tr on osf/1

From: Akim Demaille <[EMAIL PROTECTED]> Date: 25 Jul 2000 09:41:52 +0200 Paul, may I ask you what you think about this? It should be OK to set LC_COLLATE to "C", and also all the other LC_* variables: LC_CTYPE, LC_TIME, LC_NUMERIC, LC_MONETARY, and LC_MESSAGES. It shouldn't be necessar

Re: need to define _ISOC99_SOURCE

From: Akim Demaille <[EMAIL PROTECTED]> Date: 27 Jul 2000 11:31:41 +0200 Either we trace where they are needed and move _ALL_SOURCE into an AC_CHECK_FUNC or so, or we just systematically invoke them, as soon as a C compiler is wanted. It's more reasonable to move them into the C c

Re: Autoconf support for bounds checking?

From: Alexandre Oliva <[EMAIL PROTECTED]> Date: 27 Jul 2000 14:16:14 -0300 On Jul 24, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > What would be the problem with enabling the use of the fourth > parameter of AC_CHECK_FUNCS? AC_CHECK_FUNC(func, yes, no, > includes)? Eve

Re: Autoconf support for bounds checking?

From: Alexandre Oliva <[EMAIL PROTECTED]> Date: 27 Jul 2000 21:50:47 -0300 > the proposed changes don't make autoconf unusable for pre-C99. Not unusable, but it will certainly break some code. autoconf's behavior wouldn't change for existing autoconf input files. So I don't see how

Re: Autoconf support for bounds checking?

From: Alexandre Oliva <[EMAIL PROTECTED]> Date: 28 Jul 2000 00:08:31 -0300 My only concern is that we won't be verifying whether funcname is actually a function name. Unfortunately I can't think of any way to do that reliably, without having the macro caller specify a way to call the

Re: _FILE_OFFSET_BITS 64 not supported (was: Re: WARNING fileutils 4.0x-1 severly broken

From: Mark Kettenis <[EMAIL PROTECTED]> Date: Sat, 29 Jul 2000 01:22:03 +0200 Date: Sat, 29 Jul 2000 00:27:09 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> The culprit is that fileutils now defines _FILE_OFFSET_BITS 64 on the Hurd, which sucks in functions like r

Re: need to define _ISOC99_SOURCE

From: Akim Demaille <[EMAIL PROTECTED]> Date: 31 Jul 2000 12:14:49 +0200 my proposal always defines _GNU_SOURCE and _ALL_SOURCE I suggest always define __EXTENSIONS__ too. Solaris uses that symbol to define all extensions that are not incompatible with whatever standard is in use. __E

Re: need to define _ISOC99_SOURCE

From: Akim Demaille <[EMAIL PROTECTED]> Date: 31 Jul 2000 17:53:03 +0200 | And _HPUX_SOURCE ? I'd like to compile GNU packages with "cc -Aa" | instead of "cc -Aa -D_HPUX_SOURCE" on HP-UX. I was just waiting for someone to tell me it was that simple :) Unfortunately, it's not that

Re: handling of indefinitely hanging commands

From: Simon Josefsson <[EMAIL PROTECTED]> Date: 01 Aug 2000 17:54:30 +0200 Now, as it happens, sometimes CC running in AFS (a distributed filesystem) have problem with the locking mechanism for this file and hang indefinitely saying: SunWS_cache: Information: Database is locked

Re: need to define _ISOC99_SOURCE

From: Akim Demaille <[EMAIL PROTECTED]> Date: 01 Aug 2000 16:15:22 +0200 Here is a satisfying starting point? OK to commit? Not yet, unfortunately, and partly this is due to inadequate research on my part; please see below. (Sorry about that.) First, some preliminary comments: - T

autoconf, Minix, and _POSIX_SOURCE / _POSIX_C_SOURCE

Now that Minix is free software, it's higher priority for autoconf to support it more accurately. Minix is small so this should be easy to do. I just downloaded Minix 2.0 (the free version) and discovered the following: * The macro _POSIX_1_SOURCE is no longer used. So we don't need to wor

Re: expr "..." : "\(.*\)" is limited on size!

From: Akim Demaille <[EMAIL PROTECTED]> Date: 01 Aug 2000 14:52:47 +0200 Why don't we use AWK? I know it's not in the standards, but are there any good reasons for this? We could use AWK as a fallback if the standard tools fail. However, I think we can do it with the standard tools

Re: CVS autoconf is broken

Date: Thu, 10 Aug 2000 16:02:54 -0400 (EDT) From: "John David Anglin" <[EMAIL PROTECTED]> Here is a patch to correct the exit status of autoconf under hpux shells. Most of that patch is OK, but the hunks quoted below can be simplified. Just replace the "exit 2" with "exit", and similar

Re: CVS autoconf is broken

Date: Fri, 11 Aug 2000 12:30:27 -0400 (EDT) From: "John David Anglin" <[EMAIL PROTECTED]> Possibly `(exit $?); exit' could be simplified to just `exit'. Yes, that's correct. Sorry, I missed that in my earlier scan.

Re: portability of sed's \{0,1\}?

From: Jim Meyering <[EMAIL PROTECTED]> Date: 11 Aug 2000 20:11:25 +0200 I saw the earlier thread (on the autoconf list) on this topic where someone found that `?' and \| were not portable. Has anyone found a system on which \{m,n\} is not portable? Most likely, seds that don't su

Re: portability of sed's \{0,1\}?

From: Jim Meyering <[EMAIL PROTECTED]> Date: 12 Aug 2000 09:47:59 +0200 Thanks, but if no one can point to an actual system for which sed's \{m,n\} doesn't work, I'm going to document it as portable. The sed FAQ, version 014 says: * Ul

Re: portability of sed's \{0,1\}?

Date: Sun, 13 Aug 2000 10:30:21 +0300 (IDT) From: Eli Zaretskii <[EMAIL PROTECTED]> I don't see any work-arounds suggested for these problems. Does anyone know how do you express \(foo\)\{0,1\} portably? There's no simple, general substitute for \(foo\)\{0,1\}, but you can generally

Re: grep -E ? (Was: Compilation problem solved)

Date: Tue, 29 Aug 2000 10:15:13 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> grep-2.4.2 is sufficient to reproduce the problem. No need to upgrade libc - glibc-2.1.1 is fine. $ grep --version grep (GNU grep) 2.4.2 [Copyright etc skipped] $ echo foo >infile $ grep

Re: grep -E ? (Was: Compilation problem solved)

Date: Tue, 29 Aug 2000 13:27:10 -0400 (EDT) From: "Thomas E. Dickey" <[EMAIL PROTECTED]> unless I missed a response, so far all that's been demonstrated is that a newer version of GNU grep doesn't behave the same as other versions of grep. I don't even see where that has been demo

Re: grep -E ? (Was: Compilation problem solved)

Date: Tue, 29 Aug 2000 14:20:12 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> I haven't checked the older versions, but this behaviour of GNU grep is weird (it may or may not be a bug, dependent on the standard): $ echo foo |./grep -E ' *+' foo It is not a bug. GNU grep

Re: grep -E ? (Was: Compilation problem solved)

Date: Tue, 29 Aug 2000 19:07:03 -0400 From: Thomas Dickey <[EMAIL PROTECTED]> > It is not a bug. GNU grep extends the semantics of regular > expressions so that 'x*+' is equivalent to '(x*)+'. POSIX does not I wouldn't call it an extension, since it breaks some existing scripts

Re: grep -E ? (Was: Compilation problem solved)

Date: Thu, 31 Aug 2000 14:41:48 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> > If Paul said it's > ok to assume `+' is not a meta-character in `grep', I believe it. You shouldn't believe it. The answer is Plan 9. OK, but Plan 9 grep is not the same as traditional grep at al

Re: grep -E ? (Was: Compilation problem solved)

Date: Thu, 31 Aug 2000 14:41:48 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> > If Paul said it's > ok to assume `+' is not a meta-character in `grep', I believe it. You shouldn't believe it. The answer is Plan 9. OK, that's news to me. But you should be careful: Plan 9 gre

Re: Call for help on improving the documentation

Russ Allbery <[EMAIL PROTECTED]> writes: > I see software that uses ANSI C function prototypes but tests for > varargs.h vs. stdarg.h and chooses the right variadic argument syntax > accordingly. Are there really ANSI C compilers that don't have stdarg.h? No, but there were compilers that had f

Re: position of setting locale-related variables in acgeneral.m4?

From: Akim Demaille <[EMAIL PROTECTED]> User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) The failure is extremely famous, and there is an incredible amount of news in gnu.bug.utils about this but in the context of grep. It is simply that some locales have more l

Re: strings.h & string.h

From: Akim Demaille <[EMAIL PROTECTED]> User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) Werner raised this issue. I don't feel competent to judge whether it should be addressed by Autoconf or not. I'd really like to have opinions on this issue. Maybe we need

Re: Success (mostly) with the testsuite

From: Akim Demaille <[EMAIL PROTECTED]> Date: 25 Oct 2000 12:14:12 +0200 /tmp % echo "Xfoo" | nostromo 12:08 pipe> sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/p; q; } pipe quote> /^X\(\/\/\)[^/].*/{ s//\1/p; q; } pipe quote>

Re: `' quotes in messages

From: Russ Allbery <[EMAIL PROTECTED]> Date: 26 Oct 2000 17:05:05 -0700 > On a tangent, do we still want to use `...' quotes? See for an extensive argument on this subject which convinced me, even though I'm really annoyed by it.

Re: AS_DIRNAME and expr

> From: David Morgan <[EMAIL PROTECTED]> > Date: Thu, 09 Nov 2000 08:12:01 -0800 > > | > expr 'a' : '\(b\)' && echo failure > > | > > | Gives: > > | 0 > > > > Result is wrong, $? right. > Wrong explanation - no characters match so the output of 0 is correct > (At least I think so) The POSIX st

Re: AS_DIRNAME and expr

Date: Thu, 09 Nov 2000 15:24:07 -0800 From: David Morgan <[EMAIL PROTECTED]> > Sorry, I've lost context. Why is this a problem? If expr exits with > nonzero status, then AS_DIRNAME will fall back on sed, right? It will use the output of the expr and then append the output of the

Re: AS_DIRNAME and expr

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 10 Nov 2000 10:23:25 +0100 > > But our troubles could be worse than this, since `expr' is not used > only in AS_DIRNAME. For instance any CVS configure contains > > ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'` Ouch. Can you rewrite

Re: AS_DIRNAME and expr

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 10 Nov 2000 10:28:29 +0100 > > | The POSIX standard says: > | > |Usually, the matching operator shall return a string representing > |the number of characters matched ('0' on failure). Alternatively, > |if the pattern contains at leas

Re: AS_DIRNAME and expr

> From: Alexandre Oliva <[EMAIL PROTECTED]> > Date: 11 Nov 2000 04:51:04 -0200 > How about: > > # Work around the problem that "expr 'a' : 'a\(\)'" outputs "0" in QNX. > case $ac_option in > *=?*) ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'` ;; > *) ac_optarg= ;; > esac Yes, that'd be even

Re: sed usage in autoheader

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 15 Nov 2000 16:32:18 +0100 > > Do you mean `s,[^/]*$,,' would work here? Man, how can someone write > something that broken :(. Just for the record, Cray is correct: POSIX does not allow `s/[^/]*$//'. `s,[^/]*$,,' is required to work, though.

Re: FYI: Sed portability (Was: sed usage in autoheader)

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 16 Nov 2000 10:45:57 +0100 > We do agree `/foo[\/]bar/' is a single pattern which matches the > string `foo/bar', right? Then, why do you use the char class here? Because, if my admittedly fallible memory serves, some older hosts mishandle /foo\

Re: Portability of fopen (foo, "wb") (Was: bug in AC_COMPUTE_INT)

> From: Akim Demaille <[EMAIL PROTECTED]> > User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) > > But the question remains open :) I certainly recall reports of hosts where fopen (..."wb") did not work. However, I don't recall which hosts they were. I briefly looked around the

Re: AS_DIRNAME and expr

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 29 Nov 2000 12:29:09 +0100 > > it's not clear to me whether there is a difference between the > empty as a literal or as the result of an evaluation. I don't see any difference in the standard's wording. They should be treated the same. > could

Re: expr ... and `expr ...` return different results on QNX 4.2.5

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 30 Nov 2000 09:48:35 +0100 > Pavel> I don't know how many times we rely on similar > Pavel> constructs. There may be more serious problems. To fix them, we > Pavel> should never use $? after _any_ assignments. > > That's really bad in theory, I h

Re: autoconfiscating getopt_long()...

> From: Matthew Whitworth <[EMAIL PROTECTED]> > Date: Tue, 5 Dec 2000 14:45:19 -0800 (PST) > I have examined several packages that use getopt_long(), including > several GNU packages, and none of them autoconfiscate this function > the same way. Actually, few of them even autoconfiscate it at al

Re: nawk portability problem (Was: Current CVS - test suite needs gawk???)

> From: Akim Demaille <[EMAIL PROTECTED]> > User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) > | nawk: Tempcell list is curdled > | nawk: Source line number 7 > The stock nawk on Debian unstable works fine with this, and there is > not `curdled' in the man page. Maybe the aut

Re: Problem with AC_CHECK_FUNCS() and new versions of g++

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 08 Dec 2000 14:34:35 +0100 > > | #include > | /* Override any gcc2 internal prototype to avoid an error. */ > | #ifdef __cplusplus > | extern "C" > | #endif > | /* We use char because int might match the return type of a gcc2 > |builtin and

Re: [OT] waitpid()

> From: Lars Hecking <[EMAIL PROTECTED]> > Date: Thu, 18 Jan 2001 11:06:40 + > > I need to implement a configure check for waitpid(). While this by > itself is trivial, are there any known abnormalities/non-POSIXisms > I need to consider? Not as far as I know, if you confine yourself to t

Re: Rename atomicity

> From: Assar Westerlund <[EMAIL PROTECTED]> > Date: 06 Mar 2001 17:51:45 +0100 > If you're writing code that > depends on this and that has to be able to run on systems where you > cannot guarantee that rename isn't atomic, atomicity has to be > accomplished in some other way. Agreed, but I've

Re: autoconf test ': >emtpy' problem under Ultrix

> From: Jim Meyering <[EMAIL PROTECTED]> > Date: 19 Mar 2001 10:52:15 +0100 > > I'm beginning to think that Ultrix's /bin/sh is so bad that polluting, > er... changing autoconf to accommodate is may not be worthwhile. > Do any of you have an idea of how big the Ultrix-using community is? I don't

Re: Perl vs Scheme vs ML vs ... for autoconf

> From: Alexandre Oliva <[EMAIL PROTECTED]> > Date: 10 Apr 2001 08:49:15 -0300 > > I hate Perl. Really. I mean it. I wouldn't go that far. But perhaps I'm biased: * I worked down the hall from Larry Wall when he invented Perl. * In 1993 Stott Parker and I published one of the first acade

Re: config.status --version and regression testing

> From: "Tim Van Holder" <[EMAIL PROTECTED]> > Importance: Normal > Date: Tue, 10 Apr 2001 19:17:17 +0200 > > > Anyways, I've tried a slightly changed format: > > > > $ ./config.status --version > > GNU Autoconf config.status 2.49e > > configured by ../autoconf/configure, generated by GNU

Re: Perl vs Scheme vs ML vs ... for autoconf

> Cc: [EMAIL PROTECTED] > From: Akim Demaille <[EMAIL PROTECTED]> > Date: 10 Apr 2001 19:03:14 +0200 > User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) > > >>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: >

Re: Release next week?

> From: Bob Proulx <[EMAIL PROTECTED]> > Date: Tue, 10 Apr 2001 16:22:01 -0600 > > Python causes more polarization than any other language. Clearly you haven't been in the trenches of past language wars. :-) But if the principal maintainer prefers Perl, that settles the matter.

Re: Autoconf Logo?

> From: Ben Pfaff <[EMAIL PROTECTED]> > Date: 20 Apr 2001 11:21:01 -0400 > > How about jigsaw puzzle pieces that fit together. (Has that been > used elsewhere?) Yes, but we could do it better. Here's a suggestion: take the logos from the Plan of St Gall. This is a famous architectural diagram

Re: Release candidate

> From: Harlan Stenn <[EMAIL PROTECTED]> > Date: Sun, 13 May 2001 14:05:36 -0400 > > What version(s) of automake should be used with this candidate? I have been using recent CVS snapshots of automake which I got from . Currently I'm using a snapshot that I t

Re: Release candidate

> From: Harlan Stenn <[EMAIL PROTECTED]> > Date: Sun, 13 May 2001 16:14:26 -0400 > > :pserver:[EMAIL PROTECTED]:/cvs/automake Ah, so you're an old fogy too. (:-) > What, if any, is the difference between this repository and the one at > > None. "sour

Re: feature suggestion: how to figure out specific size types.

> From: Keith Bostic <[EMAIL PROTECTED]> > Date: Tue, 22 May 2001 11:00:31 -0400 (EDT) > > A feature I would like to see in autoconf is a way to find out > how to typedef to a specific size on a system. I would say that any such scheme should mimic the C99 size scheme, as it can be implemented o

Re: auxdir now?

> From: Akim Demaille <[EMAIL PROTECTED]> > User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) > > I'm for config/. No name is likely to achieve universal consensus, but "config" works for me.

Re: feature suggestion: how to figure out specific size types.

> Date: Tue, 22 May 2001 21:41:11 -0400 (EDT) > From: Keith Bostic <[EMAIL PROTECTED]> > >> Another example are applications that are written (correctly) > >> to use ssize_t. If the system has a size_t, but not a ssize_t, > >> to what type do you typedef the ssize_t? > > > > Most people use AC_C

Re: autoconf-2.50 docs: Common Behavior/Default Includes

> From: Russ Allbery <[EMAIL PROTECTED]> > Date: 28 May 2001 11:05:08 -0700 > > Lars Hecking <[EMAIL PROTECTED]> writes: > > > What's the rationale behind using inttypes.h, and not stdint.h? > > inttypes.h is more widespread on pre-C99 systems, particularly Solaris, > since IIRC it was present

Re: autoconf-2.50 docs: Common Behavior/Default Includes

> From: Lars Hecking <[EMAIL PROTECTED]> > Date: Tue, 29 May 2001 10:33:14 +0100 > > I'm unfamiliar with the C99 Standard, but did it adopt sys/types.h, No. > or define any relationship between sys/types.h and stdint.h/inttypes.h? Only indirectly. E.g. POSIX says sys/types.h defines size_t,

Re: FYI: Including stdint.h (Was: autoconf-2.50 docs: Common Behavior/Default Includes)

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 31 May 2001 09:32:23 +0200 > * acgeneral.m4 (_AC_INCLUDES_DEFAULT_REQUIREMENTS): Include > stdlib.h. > From Paul Eggert and Lars Hecking. The change itself looks good as far as it goes, but: * That Chang

Re: RFC: Changing AC_DEFINE

st tell users to get a faster shell. That will save both their time and yours. So, how about this documentation patch to address the matter? It implements the above suggestion, along with mentioning the problems with "echo" a bit more clearly (and fixing the manual to follow its own ne

Re: autoconf 2.5, 2.13, and Vim

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 11 Jun 2001 20:36:50 +0200 > Russ> If it isn't, autoconf may need to check explicitly if > Russ> and can be included at the same time, > Russ> a la the existing checks for and . > > Akim> Agreed. > > Akim> Paul, Jim? On IRIX 5.3 there are co

Re: [autoconf] AmigaOS fork()

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 11 Jun 2001 23:07:29 +0200 > > I wanted to have some feedback from Jim and Paul... If you two guys > don't have time to give a look at it, than I'll apply it on Wednesday. I read through

Re: [autoconf] AmigaOS fork()

> From: Eric Siegerman <[EMAIL PROTECTED]> > Date: Mon, 11 Jun 2001 21:19:22 -0400 > > Paul Eggert wrote: > > the Unix tradition is that code that uses 'vfork' can be safely > > changed to use 'fork' if you like. > > If this is a t

Re: autoconf 2.5, 2.13, and Vim

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 12 Jun 2001 09:56:38 +0200 > > So, are you actually saying that *any* #include should be > checked? No, just if there's a good reason for it. For example, AC_HEADER_STAT need not bother to wrap the '#include ' inside '#if HAVE_SYS_TYPES_H', sin

Re: autoconf 2.5, 2.13, and Vim

> From: Russ Allbery <[EMAIL PROTECTED]> > Date: 12 Jun 2001 05:58:31 -0700 > > I've yet to see *any* system that didn't have . I found 'AC_CHECK_HEADERS(sys/types.h)' in the configure.in files for a2ps, kaffe, and rpm. So it's plausible that some people have found such systems. (It wasn't me!)

Re: autoconf 2.5, 2.13, and Vim

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 12 Jun 2001 15:37:47 +0200 > > Well, too late, here is a proto monster patch. Unfortunately, if you wrap every include of sys/types.h, even for checks that apply only to POSIX-like systems, then you'll end up raising other questions. For example

Re: autoconf 2.5, 2.13, and Vim

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 12 Jun 2001 16:44:09 +0200 > > Including if we just use the $ac_includes_default? I'm not sure I understand this question. Presumably ac_includes_default should work on all hosts, even AmigaOS or other non-POSIX hosts, and this means ac_includes

Re: [autoconf] AmigaOS fork()

> From: Eric Siegerman <[EMAIL PROTECTED]> > Date: Tue, 12 Jun 2001 15:02:58 -0400 > > you can get away with: > #define a b > (or the equivalent using true functions) only if a()'s behaviour > is a strict subset of b()'s. That's not the case with > fork/vfork, in either direction. B

Re: [autoconf] AmigaOS fork()

> From: R. Kuhlmann <[EMAIL PROTECTED]> > Date: Tue, 12 Jun 2001 17:01:08 +0200 > > #define vfork to fork if necessary. to vfork if necessary. There's an echo in that part of the ChangeLog... In the light of the previous message, it seems to me that the patch should not alter AC_FUNC_

Re: [autoconf] AmigaOS fork()

> From: <[EMAIL PROTECTED]> > Date: Wed, 13 Jun 2001 00:07:55 +0200 > > > I don't think the uses are portable. > > Wait, why not? The latest POSIX draft says this: The vfork() function shall be equivalent to fork(), except that the behavior is undefined if the process created by vfork()

  1   2   3   4   5   6   7   8   9   10   >