> On Thu, Sep 21, 2000 at 02:56:07PM +0200, Peter Eisentraut wrote:
> > Akim Demaille writes:
> >
> > > > "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
> > >
> > > Russ> Could the really annoying "feature" of mangling the subjects of
> > > Russ> incoming messages be turned off?
> > >
>
r/printfilters/Attic/Makefile.am?rev=1.1.2.1&content-type=text/plain&cvsroot=lpr
printtool
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/lpr/printtool/Attic/Makefile.am?rev=1.1.2.1&content-type=text/plain&cvsroot=lpr
snmpkit
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/lpr/snmpkit/Attic/Makefile.am?rev=1.12.2.1&content-type=text/plain&cvsroot=lpr
tdb
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/lpr/tdb/Attic/Makefile.am?rev=1.2.2.1&content-type=text/plain&cvsroot=lpr
-ben
Bernard Dautrevaux <[EMAIL PROTECTED]> writes:
> I'm afraid I (and perhaps others) don't know "stow" :-( could
> you enlight= en us?
It's GNU software:
http://www.gnu.org/software/stow
ftp://ftp.gnu.org/pub/gnu/stow
--
Can I go now? I have a program I'm working on.
from _The
Currently, there's the broad vendor as "PC". But the target for
> SuperH is not PC.
> How should we name the vendor? Any comments are appriciated.
How about using "unknown"? ie.
sh-unknown-linux-gnu
This is what is typically done for embedded targets.
Ben
see which tokens belong
to which part of the output.
Let's stick with running the necessary commands only. Getting *any*
information will be vastly superior to what we're doing now--which is
nothing!
Ben
27;d appreciate it if the CC: to [EMAIL PROTECTED] were
preserved in replies.
Thanks,
Ben.
--- Start of forwarded message ---
Subject: Bug#58039: autoconf: AC_EXEEXT incompatible with AC_MINIX, AC_ISC_POSIX?
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Date: Sun, 13 Feb 2000 17:13:03 +
Assar Westerlund <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
> > Either I'm very confused, or it's not possible to use the autoconf
> > tests AC_EXEEXT and AC_MINIX in the same configure.in...
To clarify: actually Peter Maydell said
to be built and run. We *could* eliminate
the need for a compiler by using heredocs to carry uuencoded binaries
inside config.guess. ;-)
Ben
I suspect I built
> gcc-2.95.2 from scratch with egcs-1.1.2 and then uninstalled egcs to
> make sure that nothing could use it by mistake.
This is a known flaw in config.guess. I have every intention of fixing
it, soon. It's crazy that a script of such importance fails to use `gcc'
if `cc' isn't present.
Ben
These files are now checked out and placed in:
ftp://ftp.gnu.org/pub/gnu/config/
You can use this as a means of getting the latest versions if you'd rather
not bother with anonymous CVS.
Ben
--- start of forwarded message ---
Return-Path: <[EMAIL PROTECTED]>
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5])
by moshpit.cygnus.com (8.9.0/8.8.8-cygnus) with ESMTP id WAA19656
for <[EMAIL PROTECTED]>; Mon, 27 Mar 2000 22:23:27 +1000
Received: from ns.lst
[Problem posed is that autoconf fails when detecting endianness
for a cross-compiler.]
In GNU PSPP I attempt to detect endianness at my program's
runtime for the case of a cross-compiler. This might be
reasonable in some other cases, too.
work?
Yes. The latest version (yes, I know, it's hard to identify!) can be
fetched via FTP from ftp.gnu.org:/gnu/config/config.{guess,sub}.
> PS: And I'll bet lunch that no longer differentiating elf and non-elf
> freebsd (as of a week ago) is going to break something.
You'll need to talk to [EMAIL PROTECTED] about that (Cc'ed).
Cheers, Ben
I've been all through all the info docs that came with autoconf but I
can't seem to find this one.
How do I make my header files install in:
$prefix/include/ppd instead of just $prefix/include
-ben
echo "$version" ; exit 0 ;;
^
`- was just "version"
I'm checking the patches in now.
Thanks, Ben
Here's a somewhat old bug report that I neglected to forward
upstream earlier. This was reported against the Debian GNU/Linux
package for 2.13, but appears to be an upstream bug.
[snippage below]
--- Start of forwarded message ---
Subject: Bug#62180: autoconf: Does not detect EMX in AC_E
' script--once configured, a tree can be compiled in a
fraction of the overall time. Perhaps the introduced complexity isn't
worthwhile, but I wanted to start a discussion.
Ben
--- start of forwarded message ---
Return-Path: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
From: mike burrell <[EMAIL PROTECTED]>
Sender: "mike burrell,,," <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: proposal for autoconf languages
Date: Sat, 23 Sep 2000 1
cdir=$ac_dots$srcdir/$ac_config_dir ;;
esac
I don't see why you special case out ".". When I cut out that special
case. Things still seem to work. Is there some case that I'm not
testing in which this would cause problems.
-ben
> I think there is two problems here:
>
> Ben seems to use $srcdir where it meant $top_srcdir :-) (If we build
> in-place, then $srcdir == $builddir in all the tree).
>
> Mo on the contrary is bothered by the fact that $srcdir is relative; just
> calling "./configure
> On Oct 25, 2000, Ben Woodard <[EMAIL PROTECTED]> wrote:
>
> > I am having a problem with my configure script where when configure is
> > called for the subprojects a parameter --srcdir=. is passed into them
> > when I just do configure.
>
> srcdir is suppo
ery GNU/Linux system. The one drawback here is that it doesn't help me
determine the version of libc installed on the system--and there may even be
multiple versions. Which is the "primary"? The one that the current C
compiler will link against?
Comments, please.
Ben
rt on failures so I can add support for those
systems. Thanks,
Ben
Akim Demaille <[EMAIL PROTECTED]> writes:
> > "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
>
> Lars> Should it be a goat? I'm thinking of something to stick on the
> Lars> web pages...
>
> Would be great to have one for Libtool, one for Automake and one for
> Autoconf which would compo
This showed up in the Debian package for autoconf.
--- autoconf-2.50.orig/acgeneral.m4
+++ autoconf-2.50/acgeneral.m4
@@ -3551,7 +3551,7 @@
[AC_CONFIG_COMMANDS(default, [$2], [$3])])dnl
m4_ifval([$1$2$3],
[AC_DIAGNOSE([obsolete],
- [$0 should be used wito
The following bug was reported against the Debian GNU/Linux
package for Autoconf version 2.50. I reproduced it and didn't
see any obvious mistakes in the syntax, so I'm passing it on
upstream.
Thanks,
Ben.
--
Su
airly recently introduced bug in config.guess :-(. Another
NeXT user reported the same problem a day or two ago and I'm in the
process of fixing it now.
Ben
ch reports `fail: "0"' in my test run, whereas I expected to
see `fail: "5"' if everything were correct.
Thanks,
Ben.
--
Subject: Bug#113484: AC_TRY_RUN doesn't set $? as documented
From: Ri
The bug below was reported against version 2.50 of the Debian
GNU/Linux package for autoconf. It appears to be in version 2.52
as well.
Start of forwarded message
Subject: Bug#116744: configure --help has incorrectly formatted help
Date: Tue, 23 Oct 2001
.opengroup.org/onlinepubs/009695399/utilities/export.html
"source" is not part of POSIX.
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
[ac_cv_use_foo], [ac_cv_use_foo=no])])
Please note that the call to `AS_HELP_STRING' is *unquoted*.
It doesn't say why (and I don't know why).
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Eric Blake <[EMAIL PROTECTED]> writes:
> According to Ben Pfaff on 10/23/2008 10:06 PM:
>>> AC_ARG_ENABLE([purify],
>>> [AS_HELP_STRING([--enable-purify], [build with Purify [default=no]]),
>>
>> The Autoconf manual explicitly recommends underquoting
>
asonable reason to #include , although Konstantin
may not need those functions anyhow.
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
o the Autoconf mailing lists.
How concerned should I be in practice about Autotest changes? Is
there any chance that Autotest might be "frozen" or "stabilized"
soon?
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu
Eric Blake writes:
> According to Ben Pfaff on 7/16/2009 10:19 PM:
>> How concerned should I be in practice about Autotest changes? Is
>> there any chance that Autotest might be "frozen" or "stabilized"
>> soon?
>
> The implementation is still in
Thomas Dickey writes:
> oh... does emacs show class diagrams reconstructed from source code?
http://sourceforge.net/projects/oo-browser/
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mail
Russ Allbery writes:
> "Dr. David Kirkby" writes:
>> I'd rather not use libtool - I don't want to learn yet another
>> tool. Especially since it has already caused me some grief on Solaris.
>
> I used to feel that way, but I'm personally switching everything over to
> it, particularly as I have
Josef Vukovic writes:
> dnl (Discard to next line) is an m4 builtin while # isn't I guess, not sure.
> See also http://www.gnu.org/software/m4/manual/m4.html#Dnl section 8.1
The difference is that dnl causes text to be discarded, but #
causes text to be passed through to the output. So you can
e right track? It seems to me that there should
already be a mechanism to help with this, but I do not see one.
Thanks,
Ben.
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Bob Friesenhahn writes:
> On Mon, 5 Oct 2009, Ben Pfaff wrote:
>>
>> To try to head off the problem, I'm thinking about putting
>> something like this after each command that adds to LIBS:
>>AC_RUN_IFELSE([AC_LANG_PROGRAM([], [])],
>> [:
Bob Friesenhahn writes:
> On Mon, 5 Oct 2009, Ben Pfaff wrote:
>>
>> If your advice is correct, then any use of AC_RUN_IFELSE (if any
>> libraries are added to LIBS) must be incorrect, because Autoconf
>> does not have the correct knowledge to run a program. It'
Richard Ash writes:
> On Mon, 2009-10-05 at 12:13 -0500, Bob Friesenhahn wrote:
>> On Mon, 5 Oct 2009, Ben Pfaff wrote:
>> >
>> > To try to head off the problem, I'm thinking about putting
>> > something like this after each command that adds to LIB
Bob Friesenhahn writes:
> On Mon, 5 Oct 2009, Ben Pfaff wrote:
>>
>> I'm not sure what "be prepared for dealing with the pitfalls"
>> amounts to. Can you point to an example of a correct way to deal
>> with the pitfalls? What does your package do to de
Ralf Wildenhues writes:
> * Ben Pfaff wrote on Mon, Oct 05, 2009 at 06:20:47PM CEST:
>> To try to head off the problem, I'm thinking about putting
>> something like this after each command that adds to LIBS:
>> AC_R
"Dr. David Kirkby" writes:
> If one runs a configure script, and it needs to show a warning for
> some reason, that could be missed by someone quite easily. Is there a
> way I could insert a 10s or so pause, so it becomes more obvious, and
> they hopefully take time to read the warning?
One way
"Murray S. Kucherawy" writes:
> What's the current general wisdom on using the pkg-config
> extensions? I presume there's a reason they've not been
> incorporated into basic autoconf, so I'm keen to learn what
> common practices there are toward adopting it into people's
> builds (or avoiding it
t of macros that follows "if
> pkg-config installed then use it, else try to find stuff using
> this heuristic" exists out there someplace that I can use.
I do not know of one, but I have not looked for one.
--
Ben Pfaff
http://benpfaff.org
__
stem, you would insert `-lSM
-lICE'. Recent releases of Motif require `-lXp' and possibly `-lXpm'
as well.)
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
On Thu, Feb 11, 2010 at 11:00 AM, Konstantin Andreev wrote:
> On 11.02.10 14:37, Daniel Pocock wrote:
>>
>> I've been looking over configure.in for the Ganglia project.
>>
>> The project depends on some other libs, and their locations can be
>> specified with configure arguments, for example:
>>
>
On Wed, Feb 17, 2010 at 12:39 PM, Dr. David Kirkby
wrote:
> Ben Taylor wrote:
>>
>> On Thu, Feb 11, 2010 at 11:00 AM, Konstantin Andreev
>> wrote:
>
>>> In Solaris, libraries live in
>>>
>>> 32-bit : /usr/lib
>>> 64-bit : /usr/lib/64
&g
On Wed, Feb 17, 2010 at 4:04 PM, Bob Friesenhahn
wrote:
> On Wed, 17 Feb 2010, Ben Taylor wrote:
>>
>> Yes. I think most folks just build 32-bit stuff and are done with it.
>> Plus, with the mess that trying to guess what lib%{64} and bin%{64}
>> looks like on each
AS_ECHO' and
`AS_ECHO_N' macros, which choose between `echo -n' on
implementations where that works, `printf' if it is available, or
other creative tricks in order to work around the above problems.
--
Ben Pfaff
http://benpfaff.org
_
y writing build-time tools in a language such as shell,
Python, Perl, or awk that doesn't need to be compiled at all. If
the utility is simple, so that you could easily rewrite it in a
different language, then you might consider that solution.
--
Ben Pfaff
http:
n necessary to drag the preprocessor into it?
if (-1 >> 1 == 1)
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Dave Goodell writes:
> On Dec 10, 2010, at 11:33 AM CST, Ben Pfaff wrote:
>
>> Paul Eggert writes:
>>
>>> On 12/07/10 20:41, Mike Gibson wrote:
>>>> Does a test already exist that checks for if the >> operator in C does
>>>> arithmet
s silently. I
> was expecting an error message for this version number of GTK2.
It sounds very much like you don't have pkg-config installed.
PKG_CHECK_MODULES is part of pkg-config.
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoco
at 09:44 -0700, Ben Pfaff wrote:
>> Steve Teale writes:
>>
>> > AC_DEFUN([PKG_CHECK_MODULES])
>> >
>> > PKG_CHECK_MODULES([GTK], [gtk+-2.0 >= 3.0.0])
>> >
>> > Without the AC_DEFUN it won't run at all, contrary to most documentation I
es the JVM
have any equivalent?
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
art of the spec and thus not
> "implementation dependent" ?
That's correct, __STDC_LIMIT_MACROS is mentioned in a pair of
footnotes in C99, both of which say "C++ implementations should
define these macros only when __STDC_LIMIT_MACROS is defined
before is included."
--
Ben Pfaff
http://benpfaff.org
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
, see <http://www.gnu.org/licenses/>.
My guess is that the overall license of Makefile.in is then the
conjunction of the two, that is, GPLv3+. At any rate, the double
license is somewhat confusing, so I'd like to hear feedback in
case I'm
Daniel J Sebald writes, proposing a new
"configure" option:
> it might be something like:
>
> --builddir=DIR object and libraries
>
> which is essentially the same as doing:
>
> mkdir ../DIR
> cd ../DIR
> ..//configure OTHER_OPTS
> cd ../
Following the "configure", the next step will be
ess.
The latest version of install-sh, config.guess, etc. could live in
such a system-wide directory. Unfortunately, it's not possible to set
auxdir from the configure command line as you can with --srcdir, etc.
Ben
signature.asc
Description: Digital signature
__
When it comes to people building distro packages, here is another idea
thinking out loud. What's wrong with ..
$ find /tree/of/src/trees -name config.guess -exec ln -sf /etc/config.guess {}
\;
This puts the latest version into the tree, no patching required.
Ben
signature.asc
Descri
g.guess. We're trying to overcome
having to modify every package. Second, I don't like the idea of
doing things that surprise users. That will confuse people.
Cheers, Ben
signature.asc
Description: Digital signature
___
Autoconf mailing li
t; configure.ac where to find it.
Yes, but that requires re-running autoconf. I think we're trying to
avoid that because if configure.in is old, you may have a lot of work
to do to get autoreconf to work.
Ben
signature.asc
Description: Digital signature
your objection to the symlink/copy idea as well?
No .. I don't have any objection to that. It's a rather unobtrusive
way and will work with every package, regardless of vintage.
Ben
signature.asc
Description: Digital signature
___
I suggested a simple, low impact way of updating the files,
particularly for people wanting to build a large number of packages
(eg, for a distro). Can anyone tell me why this approach is not
satisfactory?
Ben
signature.asc
Description: Digital signature
unexpected token `newline'
./config.status: line 331: `"'
This is because line 317 of config.status (attached) has almost 3000 null
characters in it. I am completely stumped. The same thing happens in any
autotools project I try to build. Any ideas?
Thanks,
Ben
autogen.
s now disappeared! There's no
mention of any such issue in the release notes, of course...
Thanks,
Ben
From: Paul Eggert [egg...@cs.ucla.edu]
Sent: Tuesday, August 05, 2014 12:02 AM
To: Norman, Ben; autoconf@gnu.org
Subject: Re: Null characters in con
Scratch that. It is only working on "local" disk in the VM. It fails when I
run configure on a "VMWare host-guest filesystem" (e.g. folder shared from the
host). Reporting to VMWare.
-Ben
________
From: Norman, Ben
Sent: Tuesday, August
te: Wed Feb 12 22:13:37 2014 +1100
* config.guess (Linux|GNU|GNU/*): Strip extraneous whitespace
inserted by the preprocessor (eg, pgcc -E).
Cheers, Ben
signature.asc
Description: Digital signature
___
Autoconf mailing list
Autoconf
debian.org, because that allows the Debian bug tracker to
automatically track the conversation.
Thanks,
Ben.
- Forwarded message from Paul Wise -
Date: Thu, 29 Jan 2015 17:43:19 +0800
From: Paul Wise
To: Debian Bug Tracking System
Subject: Bug#776559: autoupdate: add option that repo
_SITE environment
variable?
Cheers, Ben
signature.asc
Description: Digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
ith the
> old option.
Ah, OK, thanks. The option must be old -- it's not even in Autoconf
2.10!
Cheers, Ben
signature.asc
Description: Digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
I'm adding the autoconf mailing list. For more background, take a look
at the Debian bug log:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850329
On Sun, Aug 20, 2017 at 09:18:44PM +0200, Vincent Lefevre wrote:
> On 2017-08-20 11:01:28 -0700, Ben Pfaff wrote:
> > This b
As the Debian maintainer of packaging for Autoconf, I'm
forwarding along this bug report. I don't know much about
libtool so I don't feel confident responding to it by myself.
Start of forwarded message
Subject: Bug#267140: autoconf: AC_LINK_IFELSE does n
Following bug was reported against the Debian packaging of
Autoconf. It seems like more of an upstream thing to me, because
Debian has little to do with Mac OS X, so I'm passing it along
instead of taking action myself.
Start of forwarded message
From: Jo
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> --lang* | -lcrt[[01]].o | -lcrtbegin.o | -lc | -lgcc | -libmil | -LANG:=*)
>> +-lang* | -lcrt[[012]].o | -lcrtbegin.o | -lc | -lgcc | -libmil | -LANG:=*)
>
>
r --version
Reply-To: Elrond <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Resent-From: Elrond <[EMAIL PROTECTED]>
Resent-To: [EMAIL PROTECTED]
Resent-CC: Ben Pfaff <[EMAIL PROTECTED]>
Resent-Date: Mon, 15 Nov 2004 13:03:01 UTC
Resent-Message-ID: <[EMAIL PROTECTED]>
Date:
Ross Boylan <[EMAIL PROTECTED]> writes:
> Does this just indicate that autoscan does additional stuff for people
> who have configure.ac, or is something wrong?
>
> $ autoscan --version
> autoscan (GNU Autoconf) 2.59
> Written by David J. MacKenzie and Akim Demaille.
>
> Running on Debian GNU/Linu
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> Date: Thu, 20 Jan 2005 12:35:08 +0100
>> From: Stepan Kasal <[EMAIL PROTECTED]>
>> Cc: Eric Blake <[EMAIL PROTECTED]>, autoconf@gnu.org, bug-texinfo@gnu.org
>>
>> test -f tex.exe && test -x tex.exe
>
> This will work, but is redundant: it's enou
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> From: Ben Pfaff <[EMAIL PROTECTED]>
>> Date: Thu, 20 Jan 2005 13:30:27 -0800
>> Cc: autoconf@gnu.org
>>
>> >> test -f tex.exe && test -x tex.exe
>> >
>> > This
OC properly: they are not making a replacement for
malloc() available as the Autoconf documentation says they must.
You should report bugs against these programs.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
___
Autoconf mailing l
Marc Singer <[EMAIL PROTECTED]> writes:
> On Tue, Feb 22, 2005 at 05:18:33PM -0800, Ben Pfaff wrote:
>> Marc Singer <[EMAIL PROTECTED]> writes:
>>
>> > The trouble is that I want to be able to cross compile a large
>> > number of packages without g
Marc Singer <[EMAIL PROTECTED]> writes:
> It is clear to me the intention of the AC_FUNC_MALLOC in protecting
> programs from non-conforming malloc() implementations.
By the way, malloc(0) returning a null pointer is perfectly
conforming. It is just not what some programs want.
--
I love deadli
Bernd Lachner <[EMAIL PROTECTED]> writes:
> I want more this two types of arguments for the configure script:
>
> 1)
> --device=x where x can be devicea, deviceb,
>
> This should lead for example to a #define devicea in config.h.
>
> 2)
> --devicexresoluton=x
> --deviceyresolution=y
>
> or ev
Is Autoconf the master project these days for the move-if-change script?
Thanks,
Ben
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
move-if-change currently outputs " is unchanged" when it does nothing.
This
adds undue noise in GCC builds. Would it be possible to give it more natural
behaviour like mv(1) and output nothing, regardless of whether it moves the
file?
Ben
signature.asc
Description: OpenPGP digital
I'm forwarding the following bug reported against the Debian
packaging of upstream autoconf 2.59. (Preserving the CC against
[EMAIL PROTECTED] in replies would be appreciated.)
Start of forwarded message
Subject: Bug#325866: autoconf: AC_COMPILE_IFELSE ge
Ben Pfaff <[EMAIL PROTECTED]> writes:
> I'm forwarding the following bug reported against the Debian
> packaging of upstream autoconf 2.59. (Preserving the CC against
> [EMAIL PROTECTED] in replies would be appreciated.)
Oh, crap: that should be [EMAIL PROTECTED]
--
"
The following bug was reported against the Debian packaging of
Autoconf 2.59. I verified that it produced the reported results
on my system as well.
[Preserving the CC to [EMAIL PROTECTED] in replies
would be kind, because that allows replies to be preserved in the
Debian BTS.]
[Hubert: sorry ab
Paul Eggert <[EMAIL PROTECTED]> writes:
> CVS autoconf does this instead. I presume the AC_INCLUDES_DEFAULT
> fixes the same problem in a different way?
Yes, it does. I've applied the change to Debian's Autoconf
package. Thanks for your help.
--
"Then, I came to my senses, and slunk away, hop
Keith Marshall <[EMAIL PROTECTED]> writes:
> But "Reply-to-All" is *not* the most appropriate solution --
> it's what I used here, so *you* can have *two* copies of this
> message.
Personally, I configure my mailreader to discard duplicates.
--
Ben Pfaff
emai
compiler really
exists and works, but it only gets run once per configure script,
not once per compiler.
I've tested this with Debian's Autoconf 2.59. I don't think the
situation has changed in CVS, based on a brief look at the
source, but I haven't actually tested it.
--
Ben
, e.g. the change in
the expansion of @top_builddir@ and the behavior of
AC_SUBST_FILE.
Does anyone have input on whether these changes are cumulatively
important enough to break much software?
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://be
Noah Misch <[EMAIL PROTECTED]> writes:
> On Tue, May 09, 2006 at 05:26:12PM -0700, Ben Pfaff wrote:
>> [2.59 -> 2.60 transition]
>> Does anyone have input on whether these changes are cumulatively
>> important enough to break much software?
>
> We tried to pre
Ben Pfaff <[EMAIL PROTECTED]> writes:
> One option open to me is to package and upload a 2.59 pre-release
Excuse me, I of course meant a 2.60 pre-release here.
> to Debian "unstable". I imagine that this would lead to more
> widespread testing of the pre-release,
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> Any comments on whether this is a good idea?
>
> It's a good idea, yes. You could use 2.59c. [...]
I'll try to put out a Debian package of a 2.60 pre-release in the
n
Ben Pfaff <[EMAIL PROTECTED]> writes:
> Paul Eggert <[EMAIL PROTECTED]> writes:
>
>> Ben Pfaff <[EMAIL PROTECTED]> writes:
>>
>>> Any comments on whether this is a good idea?
>>
>> It's a good idea, yes. You could use 2.59c. [...]
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> I've done this now. I actually generated it from the CVS tree,
>> for what it's worth.
>
> Thanks. Where can we get it from? I just now checked
> <http://pac
1 - 100 of 164 matches
Mail list logo
