Paul, may I ask you what you think about this?
| Akim Demaille <[EMAIL PROTECTED]> writes:
| > Wow! Thanks! Could you give more details on the failure? This is to
| > include it in the Autoconf documentation:
|
| It expands the range into a collatable range, and there are more
> "Martin" == Martin Wilck <[EMAIL PROTECTED]> writes:
Martin> I'd really like to know why at all compilers are so picky
Martin> about file suffixes - if a file has correct syntax, what the
Martin> heck does the suffix matter?
Maybe because they are actually drivers, as I think gcc is, and a
| > This is doable within .foo.bar rule, I was referring to the fact that
| > your suggestion needs an explicit rule for each object file.
|
| Not really. This should be enough:
|
| .$(CXXEXT).o: ; $(CXX) $(CXXFLAGS) -c $< -o $@
| .cc.cpp: ; $(LN_S) $@ $<
| .cc.cxx: ; $(LN_S) $@ $<
| .cc.C: ;
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jul 25, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> sometimes I believe the end user should learn to use his tools
Alexandre> Yup. But if we can help develo
> "jquantin" == jquantin <[EMAIL PROTECTED]> writes:
jquantin> Bonjours,
Hi, this list is English.
jquantin> Je travail en ce momemt á Tokyo sur un projet de portage.
jquantin> Etudiant, mon rôle est de porter un logiciel multimédia
jquantin> develloppé pour Solaris sous Linux. Biensur,
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jul 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> But you seem to say let's go for it, it cannot do harm. I think it
>> does: we might have packag
[I will probably be rejected from cygnus.com, we're black listed, but
they are working on it. If my message didn't make its way, Bruno,
could you forward it? TIA].
| Paul Eggert writes:
| > Instead, GNU applications
| > use autoconf to find out what functions are available. GNU
| > applicatio
>>>>> "James" == James Antill <[EMAIL PROTECTED]> writes:
James> Akim Demaille <[EMAIL PROTECTED]> writes:
>> Personally, I hate these macros. They should just not exist.
>> Either we trace where they are needed and move _ALL_SOURCE into
|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 reasona
Here is a proto patch. I send it mainly because I think we can
simplify the approach in Autoconf a lot: my proposal always defines
_GNU_SOURCE and _ALL_SOURCE, I don't think there is any advantage in
trying to check we run AIX before setting _ALL_SOURCE.
Also, I used a protected form for both (
| Hi!
Salut !
| I propose the following patch (against the latest CVS archive). The
| main purpose of this patch is to actually use AC_BUGREPORT somewhere ;-). I
| also took the opportunity to slightly improve different strings output by
| Autoconf, in the configure script itsel
> "drv" == Didier Verna <[EMAIL PROTECTED]> writes:
>> I'd like to stick to a single email address.
drv> I don't have really strong feelings about this, but I'd
drv> like to hear other opinions however. My main concern is that, as
drv> always, if you don't give people the means to do
| Akim Demaille writes:
| >
| > Here is a proto patch. I send it mainly because I think we can
| > simplify the approach in Autoconf a lot: my proposal always defines
| > _GNU_SOURCE and _ALL_SOURCE,
|
| And _HPUX_SOURCE ? I'd like to compile GNU packages with "cc -Aa
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Geoff Keating has just reported that Solaris'
Alexandre> /usr/ucb/expr, as well as SunOS's /usr/bin/expr, will fail
Alexandre> if the first string is longer than 128 bytes. We should
Alexandre> probably re-think our use
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Actually, what Geoff said was that the problem showed up
Alexandre> when the *matched* string was longer than 128 bytes. So
Alexandre> move the `*' into the parentheses.
F*k Sun! Why don't we use AWK? I know it's not
Well, this issue is somewhat too complex for me, I'd really like some
help at coding this into Autoconf.
Here is what I have done up to now. I'd be happy if we could
regularly commit the improvements, instead of having a growing patch.
Here is a satisfying starting point? OK to commit?
Index:
>>>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
Bruno> Akim Demaille writes:
>> +AH_TEMPLATE([_HPUX_SOURCE], + [FIXME: what's the
>> documentation?])dnl
Bruno> Well, as Paul Eggert said, it is preferrable to try to append
Bruno>
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> Not yet, unfortunately, and partly this is due to inadequate
Paul> research on my part; please see below. (Sorry about that.)
Wow, thanks Paul.
But really, personally, currently I don't have time to devote to
this. 2.50 should be c
| 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
|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 w
| 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 k
| 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--
>>>>> "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.
>>>>> "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 expand
gle tool, and still have a set up
like the grownups.
Thanks for taking the trouble of summarizing the points, and for
running them through me first. It made it clear that part of my
suggestion didn't make it to you.
On Jul 31, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> 1. my
| 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
> "Bernard" == Bernard Dautrevaux <[EMAIL PROTECTED]> writes:
Salut Bernard !
Bernard> The problem with the current aclocal.m4, is that if I
Bernard> "aclocal" and the package maintainer use some exotic macros I
Bernard> don't know about, autoconf will just generate a configure
Bernard> scri
| Akim Demaille writes:
| > | configure --version:
| > | ,
| > | | Configure script for Toto 1.0, generated by Autoconf 2.14a.
| > | |
| >
| > This is not right, the proper formatting should be what it is
| > currently:
| >
| > % ./configure --version
| &
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> What's the best way to handle getting header template stuff
Harlan> from a local macro into acconfig.h?
Harlan> It looks like aclocal does not scan acinclude.m4, which seems
Harlan> to be a logical place to look if one doesn't wa
:( 2.50 is never going to be born :( My $2.14a :)
| In several of these libraries, work-arounds have been introduced to
| avoid the AC_PROG_CC_WORKS test, that would just abort their
| configuration. The introduction of AC_EXEEXT, enabled either by
| libtool or by CVS autoconf, have just mad
> "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes:
Assar> AC_TRY_CPP only looks at stderr of the result from the
Assar> preprocessor, not at stdout. Solaris' broken cc, aka
Assar> /usr/ucb/cc, prints a message to stdout to say that it's
Assar> actually not installed, so you end up try
| On Aug 7, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| > | ifndef([AC_NO_EXECUTABLES],[
| > | AC_DEFUN([AC_NO_EXECUTABLES],[
|
| > Ahem, `AC_' is somewhat reserved to Autoconf :)
|
| Precisely. I'm suggesting autoconf to supply AC_NO_EXECUTABLES, and
| we
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Aug 7, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Are you saying you are looking for a 2.13 and 2.50 compatible
>> solution? Why?
Alexandre> Because we&#
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> Let's call it 2.14 (or 2.15 on account of the 2.14.1 incident)
Lars> or 3.0 (if it doesn't seem like "minor release" is the correct
Lars> term, the alternative is to call it a "major release").
This issue has already be beaten to death
emphasize that a patch committed is not a patch
which can no longer be discussed. And I think you can trust me to
raise the issues that really need to be discussed.
Akim
On May 10, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> So my proposal is: I can commit my patches once
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Are you saying you are looking for a 2.13 and 2.50 compatible
Akim> solution? Why?
Alexandre> Because we're not switching to CVS autoconf right now.
Akim> Can you see any other kind
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> Didn't seem like the version numbering was such a controversial
Lars> and out-debated issue, though. Each choice seemed to have it's
Lars> share of followers.
Right, and I was in favor of 2.15, but French people will tell you we
have
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> real needs, but I do believe asking something valid for both 2.50
>> and 2.13 is asking for too much.
Alexandre> You don't understand. I want something that works for 2.50
Alexandre> in 2.50. I'll take care of the fallback for
Here is my first proposal.
Index: aclang.m4
===
RCS file: /cvs/autoconf/aclang.m4,v
retrieving revision 1.57
diff -u -r1.57 aclang.m4
--- aclang.m4 2000/08/07 12:33:18 1.57
+++ aclang.m4 2000/08/09 08:05:23
@@ -481,8 +481,8 @
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Aug 9, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Here is my first proposal.
Alexandre> It's very close to what we need. I just don't like the
Alexa
> "John" == John David Anglin <[EMAIL PROTECTED]> writes:
John> On a different subject, in trying to use autoconf-2.14a to
John> regenerate configure for fileutils-4.0x, I get the error
John> _LC_LANG is not defined in AC_LANG_SOURCE. Is this a bug or has
John> there been a change in how thi
> "John" == John David Anglin <[EMAIL PROTECTED]> writes:
John> Akim,
Hi!
John> I assume the problem is for AM_FUNC_ERROR_AT_LINE, not
John> AM_FUNC_ERROR.
Yeah, sorry, it was a shorthand. It actually applies to nearly all
the AM macros.
John> As far as I can see, Jim doesn't define A
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> I have an idea. We could create AC_DEFUN_HOOK, so that we
Alexandre> could use it like this:
Alexandre> AC_DEFUN_HOOK([AM_OLD_NAME],[AC_ALIAS([AM_OLD_NAME],[AC_NEW_NAME])])
Alexandre> AC_DEFUN would then run
Alexandre>
> "John" == John David Anglin <[EMAIL PROTECTED]> writes:
John> OK. Here is a revised patch.
Thanks. Given that Paul approved it, I'll apply it, but I confess I
don't understand this part of the patch. Paul, could you explain it
to me? In fact it seems wrong to me.
--- autoconf.sh.orig
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Aug 10, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Yep, I thought about a similar thing, but I find it rather complex.
>> In addition, it opens the do
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Aug 9, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Why not, it's just too early to make a decision on this IMHO.
Alexandre> Ok, since you're desperate
... we finally have a snapshot! No, I really mean it! We have one!
Well, we will soon have one :)
This snapshot is probably not ready for full scale use, so we'd like
you guys (autoconf@) to use it as much as you can for your own
projects so that we can catch the sharp edges that remain. Dur
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Please, give a try to autoreconf and autoupdate, they are to be
Akim> evaluated too. The relationship with CVS Automake and 1.4 is
Akim> also a valuable feedback.
I forgot to mention the d
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> We should automate this process. I've wanted to for a long time.
Tom> Does autoconf have the hooks we need?
Yes it has:
- Macro: AC_CONFIG_COMMANDS_PRE(CMDS)
Execute the CMDS right before creating `config.status'. A typical
%% Alex Hornby <[EMAIL PROTECTED]> writes:
ah> Richard Stallman writes:
>> I think we need to ask the community of developers what they would
>> think of this change. It sounds good, but it could have pitfalls
>> we have not thought of.
>>
>> Would someone like to do that?
ah> I
I forgot to say that if the user wants such magic stuff, we can
document how to write the proper config.site which does that. I am
personally against having configure encode such things, it should be
entirely under the control of the user.
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Sep 4, 2000, [EMAIL PROTECTED] (Greg A. Woods) wrote:
>> [ On , September 3, 2000 at 16:44:05 (-0300), Alexandre Oliva
>> wrote: ]
>>> Subject: Re: HTML format documentation
>>>
>>> There's no need to introduce knowle
| Systems that want to
| arrange for sysconfdir to be /etc when --prefix=/usr just have to
| install /usr/(share|etc)/config.site with:
|
| test "x$sysconfdir" != 'x${prefix}/etc' || sysconfdir=/etc
|
| I think you have misunderstood what I proposed, because this would not
| i
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Sep 2, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
>> So prefix=/usr leads to syconfidir=/etc, but prefix=/usr/gnu (not
>> my idea) leads to sysconfdir=/usr/gnu/config? Ugh.
>> This nonuniformity is precisely th
| On Fri, Sep 01, 2000 at 09:38:28PM -0600, Richard Stallman wrote:
| : So prefix=/usr leads to syconfidir=/etc, but prefix=/usr/gnu (not my
| : idea) leads to sysconfdir=/usr/gnu/config? Ugh.
| :
| : This nonuniformity is precisely the intent. When prefix is a
| : subdirectory of /usr,
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello! This line needs to be rewritten so that it works both
Pavel> with autoconf-2.13 and autoconf-2.49a and causes no warnings
Pavel> from Autoconf:
Pavel> AC_MSG_CHECKING(extra library \"$i\")
Pavel> $i needs to be expanded, q
The following message is a courtesy copy of an article
that has been posted to gnu.utils.bug as well.
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Aug 18, 2000, [EMAIL PROTECTED] (Carlo Wood) wrote:
>> In the documentation of autoconf it reads that AC_TRY_RUN, w
I think the current Autoconf has solved these issues. In fact running
the test suite with CC=g++ works.
Thanks!
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> I seem to see this answer quite often to bug reports about the
Robert> currently released autoconf v. 2.13. My question is, what is
Robert> left to do before the next release? and how quickly can we
Robert> get everything done?
> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes:
Morten> As I said, a hornet's nest. Was anyone on the list aware of
Morten> these bugs?
Yep, I am, and I agree it's frightening.
Nevertheless I think that in the future, since we plan to rewrite most
of the compiler related macros, we
| I'm OK with having as many --foodir as people might want (and
| actually, I'd like to suggest that we recommend
|
| ./configure prefix=/usr
|
| This is inconsistent with the normal command line option syntax.
| We should stay with -- for consistency.
Yes, I agree. What I
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre explained very well something which concerns many of us.
It is hard to have this scheme work, and most packages have it wrong,
so basically you should just not rely on this (unless you are ready to
start again from scratc
> "Andreas" == Andreas Buschmann <[EMAIL PROTECTED]> writes:
Andreas> Hmm, I get the same problem with autoconf v2.13 and v2.14.
There is no such thing as 2.14.
Andreas> Is there a newer autoconf version than v2.14? Where do I get
Andreas> it?
ftp://alpha.gnu.org/gnu/autoconf/auto
| Thanks. I've got an updated version attached below, with the only
| additions that AC_OBJEXT is called before AC_EXEEXT in AC_PROG_CC,
| AC_PROG_CXX and AC_PROG_F77 (AC_EXEEXT uses $ac_objext).
Good!
| > I'd accept patches that do what you suggest too: have _AC_EXEEXT be
| > independent from
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Alexandre> Of course, sometimes it's convenient to change these
Alexandre> options at build time, but the potential for trouble is
Alexandre> such that I wouldn't recommend this practice.
Akim> I would even prevent this practice, ma
| For instance, if we do decide to support some --docdir, or --htmldir
| etc., in a large tree with several configures of different generations
| (which is always likely to happen), then outer configures might pass a
| --htmldir which an inner configure won't understand, and it wi
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Richard> What about other related Make variables, such as *dir? Should
Richard> they all be configure time options too?
Alexandre> Yes, and, in fact, they already are.
Richard> Not always. They are configure-time options in progr
| > There is something I like better in
|
| > ./configure --prefix=/usr bindir=/bin
|
| > over
|
| > ./configure --prefix=/usr --bindir=/bin
|
| What's wrong with:
|
| ./configure prefix=/usr bindir=/bin
|
| ? :-)
I'm very much in favor of such things, mainly beca
Are there any reasons not to merge AC_PROG_CPP into AC_PROG_CC? I'm
in the process of having the test suite correctly run AC_PROG_CC
before all the tests that need a compiler, that is, I am
AC_LANG_COMPILER_REQUIRE for all the test that compile, link and/or
run.
I still face failures for macros
Somehow we lost Richard from the thread, which is a pity since your
suggestion is good IMHO. Here's a copy of the message from Earnie.
--
--- Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> This is also why I
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello, Akim!
Hi!
Pavel> Maybe some checks will be useless for some small packages, but
Pavel> having some basic tests bundled together increases the
Pavel> probability that they are used properly and in the right order.
Absolutel
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Broken preprocessors that always fail or never produce warnings
Pavel> are rejected.
>> Maybe your patch is simplified if you consider AC_PROG_CC has
>> already been run?
Pavel> I don't think so. The preprocessor is tested for diff
| On Thu, Sep 07, 2000 at 02:12:34PM -0400, Pavel Roskin wrote:
| > -
| > However, in a few places the macros need to use brackets (usually in C
| > program text or regular expressions). In those places, they use the `m4'
| > builtin command `changequote' to temporarily change the qu
| Let me take the example of a2ps. a2ps uses a configuration file which
| is installed in syscondir. To find it the path is hard coded in a2ps,
| and a natural means to do that would be
|
| AC_DEFINE_UNQUOTED([A2PS_CONFIG_FILE], ["$sysconfdir/a2ps.cfg"])
|
| The natural way to
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Richard> Even a compatible change such as requiring all programs to
Richard> support the --foodir or --dir-foo syntax would be a hassle
Richard> for some programmers (those who don't use Autoconf), and the
Richard> change can take ye
|
| AC_CONFIG_COMMANDS_PRE(
| [LTLIBOBJS=`echo "X$LIBOBJS" | \
| sed "s/^X//;s/\\.$ac_objext /.lo /g;s/\\.$ac_objext\$/.lo/"
| AC_SUBST(LTLIBOBJS)])
|
Thanks Gary.
Personally I'm still very unhappy with \\.$ac_objext. After all,
someone might still have a .o
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> In libtool.m4 in CVS HEAD, without this patch, the tests for
Gary> AC_EXEEXT and a couple of others are inserted at the beginning
Gary> of the generated configure script.
What version of Autoconf? 2.13 has a nasty bug in AC_REQU
| > We will stay with the --foo syntax for configure options. We should
| > not change the configure syntax incompatibly unless there is a
| > pressing need for a change.
|
| Please reconsider. There is a pressing need for a change. People
| currently have to use work-arou
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Richard> Back in December we agreed to move Autoconf to subversions,
Richard> but it was delayed, and seems not to have happened yet. Can
Richard> we move it now?
It's been there for months!
http://subversions.gnu.org/cgi-
| Akim Demaille <[EMAIL PROTECTED]> writes:
| > please, tell me why you want that there are two different means to say
| > the same thing? Why do you want both
| >
| > ./configure --prefix=/foo
| > make
| >
| > and
| >
| > ./confi
>>>>> "Thomas" == Thomas Dickey <[EMAIL PROTECTED]> writes:
Thomas> On Mon, Sep 11, 2000 at 09:17:33AM +0200, Akim Demaille wrote:
>> | | This patch makes autoconf prefer configure.gnu over configure
>> when | configuring subdirectories; this is use
> "Guido" == Guido Draheim <[EMAIL PROTECTED]> writes:
Guido> As the discussion does now lead a bit elsewhere, what about
Guido> second-level options, settable via VAR=VAL (or sth. alike)?
Guido> There was the discussion that for cross-compiling, people do
Guido> often have the needs to pres
>>>>> "Guido" == Guido Draheim <[EMAIL PROTECTED]> writes:
Guido> Akim Demaille wrote:
>> See AC_ARG_VAR.
Guido> taken. ... then again, AC_CACHE_CHECK does not use
Guido> it
I don't understand what you mean. I agree some high level
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> I'm fixed now :-)
:)
Pavel> I'll try to remove changequote()s from libtool.m4 as long as it
Pavel> remains compatible with Autoconf-2.13
This is totally independent from the Autoconf release.
> "Bernard" == Bernard Dautrevaux <[EMAIL PROTECTED]> writes:
Bernard> There is one test that fails, the autoupdate test (test 111
Bernard> in my case).
This is a known problem of autoupdate: it needs a powerful sed. I'm
thinking about rewriting it in Perl. Contribution are highly
apprec
> "diger" == diger Kuhlmann writes:
> Okay, look at it that way: Let's assume I have a tree of independent
> projects to (cross-)compile. Most use autoconf, some don't, notably
> perl5. So to configure in one sweep, I have to put some replacement
> of autoconf's configure into that director
I just committed this:
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* autoupdate.sh (sed): Look for GNU sed.
(usage): Ask for GNU sed.
Index: autoupdate.sh
===
RCS file: /cvs/autoconf/autoupdat
> "Bernard" == Bernard Dautrevaux <[EMAIL PROTECTED]> writes:
Bernard> Fine for me, although I wonder why you insist at eliminating
Bernard> the "-e" sed options when there is only one sed command; I
Bernard> know in this case thay may be omitted, but I usually keep
Bernard> them for consiste
| > Yes, thank you, I know this. This is what I do. But pardon me, this
| > is by no means something I consider ``natural''.
|
| I said this is the natural way to "follow the spec". Whether it seems
| entirely natural as a way to do the job is not the question.
|
| We are not g
| CC=sun4-cc ./configure
| Hence, next time configure is run, it forgets about the CC which was
| used to build config.cache, and you get an inconsistent system.
|
| So configure needs the user to tell things instead of doing stuff in
| its back. Hence
|
|
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> XEmacs already uses --with-cc and --with-cflags,
I don't like this at all: you don't even respect the name of the
variables! It means two things to learn: the name of the variable for
make, and the interface from configure.
Russ>
> "diger" == diger Kuhlmann writes:
diger> Well... I don't have to tell you what I think about "Gnus"...
Actually it's XEmacs that is wrong I think. A friend of mine who also
used SuperCite + BBDB + Gnus + Emacs recently moved to XEmacs and
suddenly faced the same failures.
[...]
diger> S
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> So it is written. So it shall be done.
Gary> =)O|
Gary> Out of curiosity, what are the usual symptoms of theis Autoconf
Gary> 2.13 AC_REQUIRE bug?
You asked for troubles, you will have problems: here is the doc I
wrote :)
# `AC
| So maybe something like
| --set-CFLAGS=-ggdb?
|
| That is a uniform scheme but not very convenient. Since all of these
| options would be designated by us, and we would make an explicit list
| of them, we don't have to limit ourselves to a simple uniform naming
| scheme.
Please, do
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
> XEmacs already uses --with-cc and --with-cflags, although I'd tend
> to go for the shorter --cc=sun-cc and --cflags=-O2. You'd also need
> --cxx and --cxx-flags; I'm not sure what other environment variables
> are similarly specia
| Hello!
Hi Pavel, thanks for the bug report, and the fix (which is perfectly
right).
| This patch works for me, i.e. autoupdate works and the testsuite still
| passes. And even configure still works with old macros.
|
|
| --- acgeneral.m4 Thu Sep 14 23:22:57 20
601 - 700 of 1987 matches
Mail list logo
