Re: please confirm / bitte bestaetigen
On Fri, 4 Jul 2003, Peter Simons' Anti-Spam-Tool wrote: > - English - > > Because I receive several dozen spam messages each day, I installed a > small tool that will defer incoming mail message if it comes from an > address it sees for the first time. This is the case with the message > you sent me, I'm afraid. > perhaps someone should unsubscribe him -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: automake & flex's -P option
On Tue, 18 Mar 2003, Earnie Boyd wrote: > Thomas E. Dickey wrote: > > > > the autoconf maintainers do not appear to be interested in maintaining > > compatibility with lex/yacc (other than paying lip-service to the notion). > > > > Aren't you an autoconf maintainer? ;) no - I maintain a stable patch to autoconf, but am not associated with these people. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: automake & flex's -P option
On Tue, 18 Mar 2003, Richard Dawe wrote: > Hello. > > Akim Demaille wrote: > [snip] > > I think a lot could be done to improve the interface provided that we > > require Bison and Flex. The problem here stems on the willingness to > > be yacc/lex portable. > [snip] > > Out of interest: Is it a hard requirement that automake should work with lex, > yacc rather than requiring flex, bison? Or is it likely to change in the > future? the autoconf maintainers do not appear to be interested in maintaining compatibility with lex/yacc (other than paying lip-service to the notion). -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: automake & flex's -P option
On Tue, 18 Mar 2003, Akim Demaille wrote: > I don't think this is the right track, since flex and bison now > generate more that just one file. Relying on something like -o is > saner, but stdout is a dead end. yacc & clones generate two files, lex one - unless you're referring to some nonstandard usage that doesn't come to mind. In that case, there's no reason to rely on %option. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: backward compatability of tools
On Fri, 21 Feb 2003, John Burger wrote: > It seems to be explicitly against the philosophy of Autoconf to do > anything in response to particular hardware or OS versions. Rather, back to the original point - changes were made to autoconf which made it incompatible with known, widely-used versions of Bourne shell for no better reason than nicety of implementation. You don't need a special test for that. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: 1,000 year backward compatability of tools
On Wed, 19 Feb 2003, Bob Friesenhahn wrote: > On Wed, 19 Feb 2003, John W. Eaton wrote: > > > > But now? Do we really have to worry about these old systems? If > > people enjoy the vintage hardware, then is it that bad if they can > > only use vintage software on it as well? > > To install modern software on one of these vintage systems would be > like putting chrome mag wheels on a Rolls Royce. :-) to complete the analogy, with autoconf 2.57, the tires are forgotten in the rush to admire the wheels. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: Autoconf 2.54c is relased
On 4 Nov 2002, Akim Demaille wrote: >- Why should I upgrade from 2.13? more topical: why should one upgrade from 2.50-2.53? those versions are no longer maintained; they are incompatible with this week's latest design creep. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: Problems executing ./configure on Solaris
On Thu, 31 Oct 2002, Lars Hecking wrote: > > > Hi Lorrie, > > > > You are not talking to the right list. > > > > If you still think its a portability issue in ./configure, > > please trace this script with `sh -x ./configure --your-flags...' > > and send the output to [EMAIL PROTECTED] > > I don't believe there is such an issue. I have used all recebt versions of > automake and autoconf on Solaris 8, and have never seen any portability > problems. It's more likely a problem in the user's environment. The OP did an almost-immediate followup stating that the problem was due to having set bash as root's shell. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: proposal to fork the build-tools projects
On Tue, 15 Oct 2002, Tom Lord wrote: > A de facto set of bootstrap packages already exist. autoconf was > first built for those packages, and it was used to make them > extraordinarilly portable (to all unixen, VMS, and several systems > you've all but forgetten about). I've never seen the port to VMS for autoconf (but have seen mention of attempts to do so). Unless it's been done very recently, you're probably referring to a port that was apparently abandoned years ago. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: Autoconf 2.54 is released
On 13 Sep 2002, Akim Demaille wrote: > - Why should I upgrade from 2.53? > > Several bug fixes, improved portability, no known incompatibility with > 2.53, forthcoming Automake 1.7 requires 2.54. you just added one yesterday. >- Why should I upgrade from 2.13? > > This version is no longer maintained. It does not address recent > architectures, recent compilers etc. We know that upgrading from 2.13 > to 2.5x is not an easy task, especially because the Autoconf 2.13 was > extremely tolerant to incorrect macro invocations, but waiting longer > endangers the portability of your package and only delays the > conversation to newer Autoconf versions. Worse: some maintainers now > spend a significant amount of time fixing bugs in 2.13 or backporting > macros from 2.53. if any part of that were true, you wouldn't keep repeating it. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: turn off putting flex/bison output in distfile?
On 25 Jul 2002, Akim Demaille wrote: > >>>>> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes: > > Thomas> byacc is portable, and has the advantage (in contrast to > Thomas> bison) of being written in ANSI C. > > ... which is written in? bison relies on alloca, which is not standard. There are a few compilers which implement it, but the presence of nonstandard code in bison is one reason why I do not install it except for the _Very_ rare combination of a useful program which actually requires the features in bison. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: turn off putting flex/bison output in distfile?
On Thu, 25 Jul 2002, Alexandre Duret-Lutz wrote: > >>> "mcmahill" == mcmahill <[EMAIL PROTECTED]> writes: > > mcmahill> Is there a way to turn off the inclusion of lex and > mcmahill> yacc generated output in the distfile? I've seen > mcmahill> some problems where yacc on one box generates code > mcmahill> which doesn't compile on a different box (assumes > mcmahill> particular headers). > > I don't know. Why don't you install a portable yacc on your > development box? (e.g., bison) > > This way you'll distribute portable code and will not require > your users to install yacc in order to compile your project. byacc is portable, and has the advantage (in contrast to bison) of being written in ANSI C. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: install-sh posix compliance
On Thu, 27 Jun 2002, Alexandre Duret-Lutz wrote: > >>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > If nobody knows about a system which doesn't support `-a' or > `-o' alone, I'd suggest to keep using them in the Autoconf test > suite. This way we'll see failures on these systems, and can > then update the Autoconf manual with facts. or, as is the custom, insist that the shell is buggy and that one should upgrade to a "modern" version. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: Two issues with automake
On 22 Apr 2002, Akim Demaille wrote: > > | 1) I had a line like this in my configure.in: > | test -f somefile.in && AC_OUTPUT(somefile) > > Err, I suppose you mean AC_CONFIG_FILES. Two AC_OUTPUT is not > supported by Autoconf. You ought to learn to phrase your sentences using accurate terminology. It's implemented, but in the interests of providing a slightly-incompatible version, it is marked "deprecated" in the current development version of autoconf. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: Auto-tools & Win32 & Borland C++ Builder
On Wed, 23 May 2001, Axel Thimm wrote: > > [...] may be there are some hints whether people have already tried with > > borland compilers. > > Let's hope they are reading this list and will step forward to discuss it ;) sure - Borland C is much faster, and checks for errors that gcc doesn't bother to report. But there's no point in discussing it, since people who use both compilers already have their minds set. -- T.E.Dickey <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com
Re: [PATCH] etags support
On 21 Dec 2000, Tom Tromey wrote: > > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > creche. etags --version > etags (GNU Emacs 20.5) > Copyright (C) 1996 Free Software Foundation, Inc. and Ken Arnold > This program is distributed under the same terms as Emacs > > > It is pretty lame that the exuberant tags people chose to use the name > `etags' for their program. The Emacs etags has been around since 1984 actually (it's been quite a while since I looked for variants - 1994 - to find a good version, though at that time, I chose one of them), there's been more than one program named 'etags' (ditto for tags++). exuberant tags is doing what some others do: when invoked by that name, it handles the corresponding format. -- T.E.Dickey <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com
Re: Fix for script magic.
On 1 Nov 2000, Tom Tromey wrote: > Pavel> > Pavel> If you omit the space before the path, then 4.2BSD based systems > Pavel> (such as Sequent DYNIX) will ignore the line, because they interpret > Pavel> `#! /' as a 4-byte magic number. > Pavel> > > Reliable sources tell me that this is a myth albeit a pretty one. I > believe that no such system ever had this constraint. One of the > Gnitsers tested this on a Sequent DYNIX box a few years ago. 4.2's been a while ago (it's possible that it was version-specific, and true at the time) -- T.E.Dickey <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com
Re: Help-regd. error while compiling automake1.4 on hpux11.00
On 17 Oct 2000, Akim Demaille wrote: > > | I am getting the foll. error message when I am trying to build > | automake 1.4 on 11.00 hpux machine: > > You said it all: HPUX. Their Make is incredibly broken and is often > responsible of build failures. I would *strongly* encourage you to > install GNU Make and use this one only. give an example of how it's broken. -- T.E.Dickey <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com
Re: Solaris: Finds library at build-time, not at run-time.
On Wed, 26 Jul 2000, Lars Hecking wrote: > > > > Here's the thing: This works fine on Linux. I only get the error on Solaris 7. > > > I have all the latest GNU tools installed, and I'm installing the library in > > > usr/local. I am not setting LD_LIBRARY_PATH, and I use the -L/usr/local/lib > > > argument when linking the library to the program. Solaris 7 has no ld.so.conf > > > file. > > > > see the -R option of ld. > > Or the LD_RUN_PATH env variable. -R overrides that, so it's (presumably) less subject to error. -- T.E.Dickey <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com
Re: Solaris: Finds library at build-time, not at run-time.
On 26 Jul 2000, Murray Cumming wrote: > Here's the thing: This works fine on Linux. I only get the error on Solaris 7. > I have all the latest GNU tools installed, and I'm installing the library in > usr/local. I am not setting LD_LIBRARY_PATH, and I use the -L/usr/local/lib > argument when linking the library to the program. Solaris 7 has no ld.so.conf > file. see the -R option of ld. -- T.E.Dickey <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com
Re: [patch] automake: m4/depout.m4
On Wed, 7 Jun 2000, Lars J. Aas wrote: > We had some problems with getting our Coin project compiled on Cygwin, > which we traced back to some "^M"-characters that weren't removed from > directory- and file-names when the dependeny tracking files were about > to be created at the end of the config.status run. > > The following patch made the configure script work, but one should > probably find out how the ^M characters were introduced and fix it on > that side... one place to look is whether someone mounted the disk that's used for the build with a binary option (if it's mounted in binary mode, Cygwin puts ^M's on the ends of lines of "text" files). -- T.E.Dickey <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com
