Hi!
This is a patch that fixes a problem with the $? shell variable and the
AC_TRY_RUN(PROGRAM, [ACTION-IF-TRUE [, ACTION-IF-FALSE [,
ACTION-IF-CROSS-COMPILING]]]) macro. The ACTION-IF-FALSE shell command
must be run before any 'cat' or 'rm' commands, or $? from the test
program is lost.
diff -u
| In Amanda, we used to have an AC_MSG_WARN whose text contained `#'.
| It worked fine with autoconf 2.13. With CVS autoconf, we get:
|
| echo "configure: WARNING: ... #undef ..." >&m4_default([2], [AC_FD_MSG])
|
| Ideas?
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> So unless anybody decides to improve AC_CHECKING, it should IMO
Pavel> be fixed to match the documentation and let alone.
What is the behavior you people want? I'm fine with changing the
definition of AC_CHECKING in terms of AC_MS
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Can anybody update that page?
I don't know how it works to update pages there. But we will handle
all these issues once the release more or less ready.
Thanks! The current working version is fixed.
| Dear autoconf list,
| I am attempting to build the latest autoconf because it was suggested that
| this would help with build problems in libwww. The ./configure, make
| clean, and make steps went well, but make install gives errors (the first
| of several shown):
|
| doc/install.texi:19: Unk
On Aug 3, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> | In Amanda, we used to have an AC_MSG_WARN whose text contained `#'.
> | It worked fine with autoconf 2.13. With CVS autoconf, we get:
> Quote your literal argument twice.
Thanks, but I already knew how to fix it in the configure scr
|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 t
| On Aug 3, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| > | In Amanda, we used to have an AC_MSG_WARN whose text contained `#'.
| > | It worked fine with autoconf 2.13. With CVS autoconf, we get:
|
| > Quote your literal argument twice.
|
| Thanks, but I already knew how to fix it in the
Hi,
can we please change AC_PROG_RANLIB to use CHECK_TOOL?
--snip--
diff acspecific.m4.orig acspecific.m4
109a110,111
> # AC_PROG_RANLIB
> # --
111c113
< [AC_CHECK_PROG(RANLIB, ranlib, ranlib, :)])
---
> [AC_CHECK_TOOL (RANLIB, ranlib, :)])
--snip--
Yours, Rüdiger.
| Hi,
|
| can we please change AC_PROG_RANLIB to use CHECK_TOOL?
|
| --snip--
| diff acspecific.m4.orig acspecific.m4
| 109a110,111
| > # AC_PROG_RANLIB
| > # --
| 111c113
| < [AC_CHECK_PROG(RANLIB, ranlib, ranlib, :)])
| ---
| > [AC_CHECK_TOOL (RANLIB, ranlib, :)])
| --snip--
On Aug 3, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> | can we please change AC_PROG_RANLIB to use CHECK_TOOL?
> Seems fine with me.
me too
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS
On Aug 3, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Not double quoting literals with active characters is asking for
> troubles.
I see. Ok.
How about at least printing a warning?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer
On 3 Aug 2000, Akim Demaille wrote:
>
> | On Aug 3, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> |
> | What I didn't understand is why AC_FD_MSG used to be expanded in the
> | past, and it no longer was. But I've just noticed that AC_FD_MSG
> | didn't exist in autoconf 2.13.
>
> Yep, tha
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Aug 3, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Not double quoting literals with active characters is asking for
>> troubles.
Alexandre> I see. Ok.
Alexandre> How about at least printing a warning?
I've be
On Aug 3, 2000, "Thomas E. Dickey" <[EMAIL PROTECTED]> wrote:
> On 3 Aug 2000, Akim Demaille wrote:
>>
>> | On Aug 3, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> |
>> | What I didn't understand is why AC_FD_MSG used to be expanded in the
>> | past, and it no longer was. But I've just n
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> On 3 Aug 2000, Akim Demaille wrote:
>> | On Aug 3, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: | | What I
>> didn't understand is why AC_FD_MSG used to be expanded in the |
>> past, and it no longer was. But I've just notic
Hi People,
There is an active debate which started in autoconf-patches, and moved
into private messages between Alexandre and I.
We agreed we should have this thread public, and it is included below.
The first message tries to summarize the issues, but it also includes
my own opinion, which i
Hello, Akim!
> Tell me how to name it, and what's it behavior.
>
> AC_MSG_SECTION?
Not section. "Section" assumes that there is and end of
the section, which is not the case.
AC_MSG_NOTICE. It's a notice - "Hey, user, I'm going to check this and
this. Look carefully and correct me if I'm wron
| Hello, Akim!
Moin moin!
| > Tell me how to name it, and what's it behavior.
| >
| > AC_MSG_SECTION?
|
| Not section. "Section" assumes that there is and end of
| the section, which is not the case.
|
| AC_MSG_NOTICE. It's a notice - "Hey, user, I'm going to check this and
| this. Look car
> Moin moin!
:-)
>
> | config.log:
> | configure:44: notice: Checking how to work with huge files
> | configure:87: notice: Creating a 5Gb file
>
> I'm not too much in favor of an argument for this. Rather, I'd prefer
> a second AC_MSG_NOTICE. AC_MSG_SECTION for instance :) :) :)
>
> But I
# RSSH_CHECK_SUNPROC_CC([ACTION-IF-YES], [ACTION-IF-NOT])
# --
# check : are we using SUN workshop C++ compiler.
# Corresponding cache value: rssh_cv_check_sunpro_cc is set to yes or no
#
#@author Ruslan Shevchenko <[EMAIL PROTECTED]>, 1998,
#@synonpsis RSSH_CHECK_PTHREADS
# check for pthreads system interfaces.
# set CFLAGS_PTHREADS, CXXFLAGS_PTHREADS and LIBS_PTHREADS to
# flags to compiler option, which denote multithread program compilation
# (if one exists),
# and multithread library, if one required.
#
#@author (C) Ru
dnl@synopsis RSSH_ENABLE_PTHREADS
dnl
dnl modify CFLAGS, CXXFLAGS and LIBS for compiling pthread-based programs.
dnl
dnl@author (C) Ruslan Shevchenko <[EMAIL PROTECTED]>, 1998, 2000
dnl@id $Id: RSSH_ENABLE_PTHREADS.m4,v 1.4 2000/07/12 08:48:30 rssh Exp $
dnl
dnl
AC_DEFUN([RSSH_ENABLE_PTHREADS
dnl set of additional configure scripts.
dnl (C) Ruslan Shevchenko <[EMAIL PROTECTED]>, 1998, 2000
dnl $Id: RSSH_CHECK_JTC.m4,v 1.14 2000/07/19 10:19:14 rssh Exp $
dnl
dnl
dnl
AC_DEFUN(RSSH_CHECK_JTC,[
AC_ARG_WITH(jtc, [
dnl autoconf macroses for detecting ORBacus (http://www.ooc.com)
dnl (C) Ruslan Shevchenko <[EMAIL PROTECTED]>, 1998
dnl $Id: RSSH_CHECK_ORBACUS.m4,v 1.17 2000/07/07 16:09:48 rssh Exp $
dnl
AC_DEFUN(RSSH_CHECK_ORBACUS,[
AC_REQUIRE([AC_PROG_CC])dnl
AC_REQUIRE([AC_PROG_CXX])dnl
AC_REQUIRE([AC_PRO
The following docs for CORBA support must be published in archive near
my CORBA support macroses.
[I will be happy, If anybody will review this, and may be correct my
ugly English]
CORBA-autoconf.tex
CORBA-autoconf.pdf
Sheesh you guys!
Why don't you do real work instead of arguing about this tiny little
point. I suggest you (Alexandre) agree to let Akim change autoreconf
the way he proposed, for now. Then, later, if enough maintainers write
testimonials about how hard it is to have their package distribution
I'm going to agree with Jim. I like the idea of separate files for different
functions. It's easier to debug and correct that way.
Regards,
Earnie.
--- Jim Meyering <[EMAIL PROTECTED]> wrote:
> Sheesh you guys!
>
> Why don't you do real work instead of arguing about this tiny little
> point.
On Aug 3, 2000, Jim Meyering <[EMAIL PROTECTED]> wrote:
> we'll never be able to go back to a simpler and cleaner approach.
The problem is that I don't agree that keeping multiple m4 files in
the source tree is a simpler and cleaner approach. I think
maintaining a single aclocal.m4 is simpler
Alexandre Oliva <[EMAIL PROTECTED]> writes:
| On Aug 3, 2000, Jim Meyering <[EMAIL PROTECTED]> wrote:
|
| > we'll never be able to go back to a simpler and cleaner approach.
|
| The problem is that I don't agree that keeping multiple m4 files in
| the source tree is a simpler and cleaner approach
On Aug 3, 2000, Jim Meyering <[EMAIL PROTECTED]> wrote:
> As I said before, Akim's approach is a strict subset of yours, so it is
> obviously simpler *to implement*.
But it's not simpler to use, and that's why I'm fighting so much for
my point. I don't care about what design is easier to imple
32 matches
Mail list logo
