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!
>--[Bernard Dautrevaux]--<[EMAIL PROTECTED]>
> >--[Alexandre Oliva]--<[EMAIL PROTECTED]>
> > >--[Jim Meyering]--<[EMAIL PROTECTED]>
> > > 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
Hi!
>--[Akim Demaille]--<[EMAIL PROTECTED]>
> ... we finally have a snapshot! No, I really mean it! We have one!
> ps/ Jim, could you please upload 2.49a in
> ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.49a.tar.gz
Looks like it's still not there... :(
Anyway, I have some questions r
Hi!
> Another problem I have is the following: When configuring a source tree
> of unrelated projects, I sometimes want to give configuration options
> for a specific project
Sometimes it helps to look how other people do it. What about this patch:
--snip--
diff -u -r autoconf/acgeneral.m4 aut
Hi!
Using autoconf 2.49a, I often found fi's glued to following commands.
Obviously, a newline is missing. The cause is an ARG_WITH or ARG_ENABLE
command with a dnl at its end - autoconf 2.13 seems to have generated a
bogus newline, so that "everyone" removed it with a dnl. So either remove
the
>--[David Morgan]--<[EMAIL PROTECTED]>
> > --- Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > > I fully support making "docdir" a separate directory that defaults to
> > > `${prefix}/doc' -- after all, this has been reality for years. But I'd
> > > like to see this taken further: make "info" a s
Hi!
>--[Alexandre Oliva]--<[EMAIL PROTECTED]>
> But it's supposed to be. We'd appreciate any bug reports exposing
> incompatibilities.
Really? <[EMAIL PROTECTED]>
And what about the patches in
<[EMAIL PROTECTED]> ?
Yours, Rüdiger.
Hi!
>--[Greg A. Woods]--<[EMAIL PROTECTED]>
> [ On , September 6, 2000 at 21:57:04 (-0700), Russ Allbery wrote: ]
> very different in what they do. Indeed it should be possible to adjust
> ${DESTDIR} during "make install" (and it would only have effect during
> "make install"). $(prefix) spec
a part of
<[EMAIL PROTECTED]>.
Index: ChangeLog
from Rüdiger Kuhlmann <[EMAIL PROTECTED]>
* acgeneral.m4(_AC_OUTPUT_SUBDIRS): check for configure.in as well
Index: acgeneral.m4
===
RCS file: /cvs/autoconf/ac
"fiecho" or "fielse" to be a "fi" command.
While the "dnl" may be bad practice, this breaks v 2.13 scripts. Here's a
patch to fix it - just add a semicolon, so no line is wasted, yet no
commands are glued together.
This is basically a resend of
<
"Configure". Hence, I have to choose a different
name - configure.gnu. Or do you prefer a different name?
> This is wrong: you should update the --help recursion too.
The Q. is, whether --help does make sense in this situation. But I guess you're
right.
Okay,
Hi!
>--[Akim Demaille]--<[EMAIL PROTECTED]>
> > "diger" == diger Kuhlmann writes:
Well... I don't have to tell you what I think about "Gnus"...
> Still, why don't you want both Configure and configure in the same
> dir? Are you using a case insensitive FS?
AmigaOS filesystems are tradit
than `.ac', since only the
> interface matters, and this interface is dictated by the GNU coding
> standards, not by the Autoconf CS.
Cool :).
> So I'm now in favor of this patch with one regret though: it's lacking
> the documentation part. If this goes into
m has a BSD-style getpgrp(),
@@ -1442,6 +1443,39 @@
AU_ALIAS([AC_UTIME_NULL], [AC_FUNC_UTIME_NULL])
+# AC_FUNC_FORK
+# -
+AC_DEFUN([AC_FUNC_FORK],
+[AC_CACHE_CHECK(for working fork, ac_cv_func_fork_works,
+[AC_TRY_RUN([/* By Rüdiger Kuhlmann. */
+#include
+#include
+#include
+#if HAVE_UNI
>--[Tim Van Holder]--<[EMAIL PROTECTED]>
> For the cross-compiling case, I think
Okay, what about this: It doesn't #define fork anymore, but HAVE_FORK if it
works. Then the program has to check this itself.
2001-05-24 Rüdiger Kuhlmann <[EMAIL PROTECTED]>
>--[Russ Allbery]--<[EMAIL PROTECTED]>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
[Yes, I do read the mailing lists I'm writing to. I even set a
Mail-Followup-To:]
> > The key question here is, if a program requires fork(), would it
> > normally work with Amiga's vfork()? My guess is no, s
Ehm, what do you want me to change to have this patch accepted?
Yours, Rüdiger.
--
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi
rkvfork fork
#else
#if HAVE_WORKING_VFORK
#define forkvfork vfork
#else
#error Neither fork nor vfork available.
#endif
#endif
to confdefs.h and replace fork by forkvfork where appropriate. forkvfork in
the sense of prefer fork, but replace by vfork. Comments about that?
2001-05
>--[Tim Van Holder]--<[EMAIL PROTECTED]>
> On 31 May 2001 15:15:49 +0200, Rüdiger Kuhlmann wrote:
> Akim was talking about the 'case "$host"', I think.
> The problem is that since we are testing whether a function works, we
> need to _run_ that fun
e you German? :) s/ist/is/.
Yes, I am. Damn! Usually I notice such stuff myself...
Btw, why does AC_FUNC_FNMATCH define HAVE_FNMATCH instead of
HAVE_WORKING_FNMATCH?
Next try:
2001-05-31 Rüdiger Kuhlmann <[EMAIL PROTECTED]>
* acfunctions.m4: (AC_FUNC_FORK) New, check whether fork
the result.
> | Btw, why does AC_FUNC_FNMATCH define HAVE_FNMATCH instead of
> | HAVE_WORKING_FNMATCH?
> Because of (*£&$(*£R history, and backward compatibility. But you are
> right, let's define the proper name too.
Okay :-)
2001-06-01 Rüdiger Kuhlmann <[EMAIL PROTECTED
>--[Rüdiger Kuhlmann]--<[EMAIL PROTECTED]>
> 2001-06-01 Rüdiger Kuhlmann <[EMAIL PROTECTED]>
>
> * acfunctions.m4: (AC_FUNC_VFORK) renamed to _AC_FUNC_VFORK. Remove
> AC_DEFINEs and don't guess cross-compilation values.
> (_AC_FUNC_FO
so
> long as "if you like" is always equivalent to "never" under AmigaOS.
Okay, I changed the doc to suggest to define vfork yourself, either when
!HAVE_WORKING_VFORK, or if you prefer to use fork, when HAVE_WORKING_FORK.
> I would replace this code with
>--[Paul Eggert]--<[EMAIL PROTECTED]>
> ... Kuhlmann's patch ...
*giggle* feel free to use my first name.
> I don't think the uses are portable.
Wait, why not? And if they aren't, would it be okay to change the
HAVE_WORKING_VFORK to !HAVE_WORKING_FORK?
> > The forkvfork() idea would be safes
>--[Paul Eggert]--<[EMAIL PROTECTED]>
> > > I don't think the uses are portable.
> > Wait, why not?
> The latest POSIX draft says this:
> [...]
Okay.
> > And if they aren't, would it be okay to change the
> > HAVE_WORKING_VFORK to !HAVE_WORKING_FORK?
> No. For AC_FUNC_WAIT3 and AC_SYS_RESTART
Hi!
Since the discussion stopped, can we agree on the following patch? Feel free
to add more documentation on fork() vs vfork() later.
2001-06-15 Rüdiger Kuhlmann <[EMAIL PROTECTED]>
* acfunctions.m4: (AC_FUNC_VFORK) renamed to _AC_FUNC_VFORK. Remove
AC_DEFINEs and
2001-06-15 Rüdiger Kuhlmann <[EMAIL PROTECTED]>
* acfunctions.m4: (AC_FUNC_VFORK) renamed to _AC_FUNC_VFORK. Remove
AC_DEFINEs and don't guess cross-compilation values.
(_AC_FUNC_FORK) New, check whether fork() isn't just a stub.
(AC_FUN
>--[Alexandre Oliva]--<[EMAIL PROTECTED]>
> On Jun 13, 2001, Rüdiger Kuhlmann <[EMAIL PROTECTED]>
>wrote:
> > Wait, I disagree. If there is no fork()
> perhaps we can use a spoon()? Hmm, no, we have to remember ``there's
> no spoon'' either. :
>--[Eric Siegerman]--<[EMAIL PROTECTED]>
> On Mon, Jun 18, 2001 at 03:29:17PM +0200, Rüdiger Kuhlmann wrote:
> > [fork + vfork + ac_fork + ac_vfork]
> > I guess you know _I_ agree, but "the others" don't seem so.
> Suits me just fine.
Hi!
I'd like to re-kindle the discussion about options for where to put a
programs documentation by suggesting the following patch:
2001-06-19 Rüdiger Kuhlmann <[EMAIL PROTECTED]>
* acgeneral.m4: (_AC_INIT_PARSE_ARGS) Add switches for install
dirs of documentation
Hi!
>--[Russ Allbery]--<[EMAIL PROTECTED]>
> Rüdiger Kuhlmann <[EMAIL PROTECTED]> writes:
> > I'd like to re-kindle the discussion about options for where to put a
> > programs documentation by suggesting the following patch:
> Wouldn't some sor
>--[Akim Demaille]--<[EMAIL PROTECTED]>
> Paul, this patch was sent later, and you did not comment it.
Does silence means it is refused? Come on, whoever has some authority on
this subject, say something, you aren't Dave Zaroski, are you?
> 2001-06-19 Rüdiger Kuhlma
>--[Tom Lord]--<[EMAIL PROTECTED]>
>> It could be that we should tell people to use Bash to build
>> GNU packages if their native shells have trouble handling the
>> job. That would be a smaller change and perhaps worth doing.
> How is `bash' built?
> >> You need
>--[Paul Eggert]--<[EMAIL PROTECTED]>
> Dan Kalowsky <[EMAIL PROTECTED]> writes:
> > - there is no native shell environment yet, so everything needs to use
> > cross build tools. Besides setting the CC flag, is there some way to
> > automate this?
> Setting CC etc. is the usual way.
Am I mi
>--[Bruno Haible]--<[EMAIL PROTECTED]>
> * lib/autoconf/general.m4: Add new configure option --localedir.
> * doc/autoconf.texi (Installation Directory Variables): Document
> localedir.
The question is: why not create an autoconf macro to define arbitrary
installation directori
>--[Bruce Korb]--<[EMAIL PROTECTED]>
> Bob Friesenhahn wrote:
> > On Wed, 18 Feb 2004, Daniel Reed wrote:
> > > On 2004-02-18T00:31-, Balint Joo wrote:
> > > ) /* Name of package */
> > > ) #define PACKAGE "qdp"
> > > ...
> > > ) The trouble is that when we configure two packages,
> ...
> > >
36 matches
Mail list logo
