h are only implemented for a subset
of all possible targets, therefore the information provided by means of
canonicalization can be applied to implicitly disable/enable package
features).
(this is my understanding, but I have poor
knowledge).
Ralf
--
Ralf Corsepius
Forschungsins
)
Copyright 1998 Free Software Foundation, Inc.
[Original SuSE 6.3 binary]
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http
rning, Morning", meaning "Good Morning, Good Morning", pronounced
similar to the English word "coin".
[They use it the whole day, even at night, in a similar way to Americans
using "Hi" :)]
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wi
Akim Demaille wrote:
"Ralf" == Ralf Corsepius [EMAIL PROTECTED] writes:
Well, I hear you Pavel. I'm going to rewrite my patch, and submit
it. It will try to warn when --host, --build or --target is used
when it is not supposed to be.
Ralf I hope you consider that p
. from the shell, I don't see
how this can ever work.
Eg.:
./configure --host=sh-unknown-coff
- bigendian
make CFLAGS=-ml
- host in reality is little endian.
Ralf.
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany
-toolchains distributed with their
distributions (IMHO, an uncredible decision ;).
However, a PC still remains a PC and is not a SuSE, RH, Debian or
whatsoever machine.
Imagine the consequences of:
./configure --build=i386-suse-linux-gnu --host=i386-redhat-linux-gnu
Ralf.
--
Ralf Corsepius
figure scripts which rely on the values of host,
build, target without using AC_CANONICAL_*, esp. in packages not
using automake/config.guess/config.sub.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +4
1 | sed 's%/[[^/][^/]]*$%%'])
Is this supposed to work with DOS-Paths and DOS-Drive-letters?
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-
"Lars J. Aas" wrote:
On Wed, Jul 05, 2000 at 05:12:19PM +0200, Ralf Corsepius wrote:
: "Lars J. Aas" wrote:
:
: +# AC_SHELL_DIRNAME(PATHNAME)
: +# --
: +# Remove last slash and trailing text.
: +# Not all systems have dirname, so we
/subversions/autoconf/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory
`/usr/local/src/packages/subversions/autoconf/tests'
make: *** [check-recursive] Error 1
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm
$srcdir/.. $srcdir/../..)])
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni-ulm.de
know, I could have used $GCC instead of ac_cv_prog_gcc :)]
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni
file
names.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni-ulm.de
tem.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni-ulm.de
tools/libs)
CC=i386-cygwin-gcc configure --build=i386-cygwin --host=i386-cygwin
Further issues arise when installing *.[o|obj] files:
i.e. a compiler's chain's startup files or customized startup files
(a very common case for embedded systems).
Ralf
--
Ralf Corsepius
Forschungsins
# /opt/cygwin/bin/i386-pc-cygwin-gcc hello.c
# ls
a.exe hello.c
# /opt/cygwin/bin/i386-pc-cygwin-gcc --version
2.95.2-5
Ralf.
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL
without AC_PROG_CC, but using cpp alone, without using a
c-compiler indeed gives sense:
There is one very popular tool applying this approach: imake :)
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel
.obj
# ls --version
ls (GNU fileutils) 4.0
# uname -s -m -r
Linux 2.2.18-SMP i686
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-
"Lars J. Aas" wrote:
Having one semi-functional compiler wrapper for MS Visual C++, and
another one for Borland C++ coming along nicely, I've started thinking
of how this should be integrated with the Auto-tools.
What I have come up with is a scheme something like this:
1) The scripts
support (cf.
config-ml.in, used by the gnu toolchain and many other packages).
AFAIS, apparent cause is autoconf-2.[4]* placing INIT-COMMANDS
before the CONFIG_FILES section in config.status, and the
CONFIG_FILES section working on variables which had been constant
with autoconf-2.13.
Ral
.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni-ulm.de
on the same data on every host.
Independent of this, a test (outside of the testsuite) to check
existing config.sites would also be useful.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
configure 2.49e is supposed to be -- at least, I
have never heared of it :)
Probably "created by configure generated by autoconf 2.49e" or even
simply using "configure" would be more correct and less confusing.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer A
om file.yy
by GNU Bison version 1.25
*/
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni-ulm.de
Akim Demaille wrote:
Let's flush all the documentation related patches, Lars' cleanups, and
target an actual release next week.
I am in favor for letting autoconf-2.50 be preceeded by a at least 4
weeks long "code-freeze", "inevitable bug-fixes only" and "no new
features/cleanups" phase.
Akim Demaille wrote:
"Ralf" == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf Akim Demaille wrote:
Let's flush all the documentation related patches, Lars' cleanups,
and target an actual release next week.
Ralf I am in favor for letting autoconf-2.50 be preceeded by a at
Akim Demaille wrote:
"Earnie" == Earnie Boyd [EMAIL PROTECTED] writes:
Earnie Alexandre Oliva wrote:
On Apr 12, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
aux means nothing and is not portable. auxdir is puke puke puke
Agreed. I still like AC_CONFIG_SUPDIR better than
-DHAVE_CONFIG_H -I. -I. -I. @CPPFLAGS@ -g -O2 -c hello.c
gcc: @CPPFLAGS@: Datei oder Verzeichnis nicht gefunden
make: *** [hello.o] Error 1
The return of a N'aucun ficher ou repertoire / No such file or
directory bug :)
Ralf.
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte
Lars J. Aas wrote:
Hi,
Shouldn't we push Autoconf out the door soon? I don't see the point in
delaying the release any longer. Nothing seems to be going on, so I
propose that we make a 2.50 branch and release 2.50 from it. Then we can
continue general development in HEAD while
Akim Demaille wrote:
| AFAIS, one cause for this to happen at all, is presence of /lib/cpp
| in this fragment from AC_PROG_CPP:
|
|# Double quotes because CPP needs to be expanded
| for CPP in $CC -E $CC -E -traditional-cpp /lib/cpp
| do
|
Akim Demaille wrote:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf Hmm, I think we might be talking past each other:
Ralf All I am trying to say is: This check checks for a tool which is
Ralf not applicable/illegal to use for cross compilation (/lib/cpp is
Ralf a native build
Alexandre Oliva wrote:
On May 11, 2001, Ralf Corsepius [EMAIL PROTECTED] wrote:
Are you thinking about something in analogy to AC_CHECK_TOOL
($target-cpp or similar?). At least the gnu toolchain does not have
such a beast, but it might be worth checking for in the cross
compilation
Hi,
With autoconf-cvs AC_EXEEXT doesn't do anything anymore. I.e.
configure-scripts which are using AC_EXEEXT, but do not explicitly
call AC_PROG_CC, silently break with autoconf-cvs (@EXEEXT@ will not
be substituted).
Can't autoconf at least warn about using AC_EXEEXT w/o AC_PROG_CC?
Ralf
Tim Van Holder wrote:
On 16 May 2001 00:22:43 +0200, Ralf Corsepius wrote:
Until now this package's configure.in has been using AC_EXEEXT alone
(w/o AC_PROG_CC), now I seem to need adding AC_PROG_CC, but ..
.. Adding AC_CANONICAL_HOST would give sense, but this also
apparently isn't
. recent
developments in autoconf, but it describes the basic working
principles and is rather detailed.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX
Mike Castle wrote:
On Thu, May 24, 2001 at 11:37:22AM +0200, Peter Eisentraut wrote:
Mike Castle writes:
How do you reference the generated make file?
include $(top_builddir)/Makefile.global
This requires that you set top_builddir somewhere.
Well, that's the magic I was
Tim Van Holder wrote:
On 29 May 2001 23:20:26 +0200, Teun Burgers wrote:
Hi
I am maintaining the configure script for
gnugo (http://www.fsf.org/software/gnugo/)
Under autoconf 2.13 when you had AC_EXEEXT
in you configure.in you could do under cygwin
a mingw32 build as follows:
David Burg wrote:
Hello,
I hope outlook will let this real plain text ! ;-) Well, I'm trying to make
a configure.in file that support Canadian Cross compiling with the help of
the autobook 1.3.
Well, I actually doubt you really want to build Canadian Cross, but
to be trying to implement
Pavel Roskin wrote:
Hello, Ralf!
Hi Pavel,
How about merging AC_PROG_CPP and AC_PROG_CC together?
What's the point of keeping the two of them?
* Some tools (eg. imake) apply cpp as macro-processor, even if cc is
not available on a particular installation. Other
Akim Demaille wrote:
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan This sounds familiar to me - I think I ran in to the same
Harlan problem under FreeBSD on a configure.in script that only
Harlan wanted to find the X directories (header and libs). I had to
Harlan specify
David Burg wrote:
Hello,
Well, two weeks ago all was fine. A simple
./configure --host=arm-linux --build=i686-pc-linux-gnu
was at last working correctly.
Only if using autoconf 2.13
As you can see, it choose the wrong compiler unless I force it. But I have
check in cvs, the
Guido Draheim wrote:
Earnie Boyd wrote:
Rüdiger Kuhlmann wrote:
Hi!
-8-
AC_SUBST([infodir],['${prefix}/info'])dnl
+AC_SUBST([docdir], ['${datadir}/doc'])dnl
AC_SUBST([mandir], ['${prefix}/man'])dnl
In my simplistic mind having three
Akim Demaille wrote:
| How about merging AC_PROG_CPP and AC_PROG_CC together?
|
| What's the point of keeping the two of them?
| * Some tools (eg. imake) apply cpp as macro-processor, even if cc is
| not available on a particular installation. Other tools might want
|
Gary V. Vaughan wrote:
On Friday 22 June 2001 11:20 am, Tilo Riemer wrote:
what is wrong if I get the following error:
libtool: ltconfig version ' does not match ltmain.sh version 4a'
You are using a mismatched ltmain.sh and ltconfig from different versions of
libtool.
IIRC, I have
Akim Demaille wrote:
hi Ralf,
Hm, I don't understand how it happened. Could you send config.log?
Enclosed below.
Or at least the part where configure is looking for a preprocessor?
I fail to understand why it refused to use `compiler -E'.
It seems to me that CC somehow does not get
Peter Eisentraut wrote:
Akim Demaille writes:
Also, (the question might have already been asked, but I confess the
answer escapes me): why don't we AC_CHECK_TOOL for cpp? And then fall
back to /lib/cpp if available.
Because cpp is not a cross tool,
Hmm, I beg to differ.
Actually,
Hi,
A simple question:
How to write '[' and ']' in AC_HELP_STRING with autoconf-2.5x?
Background:
I would like to use a help string (configure --help) similar to
this:
--enable-some-feature=[foo|bar] explanation [default:foo]
Ralf
Paul Eggert wrote:
From: Lars Hecking [EMAIL PROTECTED]
Date: Tue, 24 Jul 2001 19:36:00 +0100
Some hints on how to have configure.in compatible with both versions
would be more than welcome.
The most important bit of advice is to stick only to 2.13-style
features, and to avoid
Bernard Dautrevaux wrote:
-Original Message-
From: Ralf Corsepius [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 25, 2001 10:38 AM
To: Paul Eggert
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Autoconf 2.52 is released
Paul Eggert wrote:
Date: Wed, 25
Am 01 Aug 2001 19:40:38 +0200 schrieb Akim Demaille:
I've just uploaded Autoconf 2.52b (for Autoconf 2.52a was broken, of
course...).
It might seem a bit premature, but recently there have been dramatical
changes in Autoconf:
1. The package layout has completely changed
AFAIS, aclocal
Am 04 Aug 2001 16:55:21 +0200 schrieb Akim Demaille:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
hi!
1. The package layout has completely changed
Ralf AFAIS, aclocal still applies $PREFIX/aclocal. However, autoconf
Ralf does not put any files into it. I.e. when installing
Am 09 Aug 2001 11:40:06 +0200 schrieb Akim Demaille:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf Though I agree that it would be desirable to let autoconf do
Ralf this cleanup, I fail to see how autoconf could do this job.
I thought several times about the fact that some clean
Am 15 Aug 2001 09:44:00 -0500 schrieb Paul Martinolich:
Sorry, I was unclean. I'll give it another shot. I have this structure
../src
../pkgA
../pkgB
src contains my application. Platform A does not provide the third party
pkgA which I need in the application, whereas Platform
Am Mit, 2001-10-31 um 22.22 schrieb Thomas Dickey:
On Wed, Oct 31, 2001 at 06:23:46AM -0500, Thomas E. Dickey wrote:
On 31 Oct 2001, Akim Demaille wrote:
Thomas == Thomas Dickey [EMAIL PROTECTED] writes:
Thomas there were claims on this mailing list that 2.50 was 3 times
Thomas
Am Sam, 2001-11-17 um 04.29 schrieb Harlan Stenn:
AC_CANONICAL_TARGET and then
case $target in
*-*-linux*)
...
;;
*-*-freebsd*)
...
;;
...
esac
($target doesn't need the quotes, but I do them anyway.)
Sorry, $target is meant to be used for cross-tools, $host is
Am Don, 2001-11-08 um 17.56 schrieb Akim Demaille:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf If using AM_CONFIG_HEADERS located in subdirectories, make
Ralf distcheck breaks because of not correctly handling stamp*-files.
Ralf .. make[1]: Leaving directory `stamp-test-0.0
Am Sam, 2001-12-01 um 00.01 schrieb Christian Ohm:
hi.
i filed the following bugreport for autoconf 2.13 for debian.
- Forwarded message from Christian Ohm [EMAIL PROTECTED] -
Date: Mon, 12 Nov 2001 02:28:10 +0100
From: Christian Ohm [EMAIL PROTECTED]
To: Debian Bug Tracking
Am Son, 2002-01-27 um 02.30 schrieb Michael Goetze:
config.guess returns CPU-Vendor-OS, not CPU-VENDOR-Kernel.
I've never quite understood what the vendor is supposed to mean, exactly.
IIRC, it originally meant to be a unique string to identify a particular
board-HW. This also manifest
Am Mit, 2002-01-30 um 14.15 schrieb Akim Demaille:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf If using the new AC_INIT and AM_INIT_AUTOMAKE syntax, PACKAGE
Ralf gets translated to lower case letters. - Why this change?
Because that's the case for most packages. But that's
Am Don, 2002-01-31 um 02.21 schrieb Tom Tromey:
Akim == Akim Demaille [EMAIL PROTECTED] writes:
Ralf If using the new AC_INIT and AM_INIT_AUTOMAKE syntax, PACKAGE
Ralf gets translated to lower case letters. - Why this change?
Akim Because that's the case for most packages.
I think the
Am Don, 2002-01-31 um 12.09 schrieb Akim Demaille:
Tom == Tom Tromey [EMAIL PROTECTED] writes:
Akim == Akim Demaille [EMAIL PROTECTED] writes:
Ralf If using the new AC_INIT and AM_INIT_AUTOMAKE syntax, PACKAGE
Ralf gets translated to lower case letters. - Why this change?
Akim Because
Am Don, 2002-01-31 um 15.16 schrieb Akim Demaille:
| Am Don, 2002-01-31 um 12.09 schrieb Akim Demaille:
| Tom == Tom Tromey [EMAIL PROTECTED] writes:
|
| Akim == Akim Demaille [EMAIL PROTECTED] writes:
| Ralf If using the new AC_INIT and AM_INIT_AUTOMAKE syntax, PACKAGE
| Ralf
Am Don, 2002-01-31 um 16.50 schrieb Tim Van Holder:
On Thu, 2002-01-31 at 16:21, Ralf Corsepius wrote:
Given an autoconf-2.52 and automake-1.5 compatible configure.in:
..
AC_INIT
..
AM_INIT_AUTOMAKE(libXrc, 0.1)
..
make dist produces libXrc-0.1.tar.gz, PACKAGE is set to libXrc
Am Don, 2002-01-31 um 17.25 schrieb Alexandre Duret-Lutz:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
[...]
Ralf Example:
Ralf Given an autoconf-2.52 and automake-1.5 compatible configure.in:
Ralf ..
Ralf AC_INIT
Ralf ..
Ralf AM_INIT_AUTOMAKE(libXrc, 0.1)
Ralf
Am Don, 2002-01-31 um 17.27 schrieb Russ Allbery:
Akim Demaille [EMAIL PROTECTED] writes:
Automake names PACKAGE what Autoconf name PACKAGE_TARNAME. In addition,
Autoconf support PACKAGE_NAME. Because in many cases PACKAGE_TARNAME
can be computed from the PACKAGE_NAME, such a _default_
Am Don, 2002-01-31 um 22.31 schrieb Alexandre Duret-Lutz:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf Am Don, 2002-01-31 um 17.27 schrieb Russ Allbery:
[...]
Why are you lowercasing the package name?
For the same reason a leading `GNU ' is stripped: because for
most
Am Fre, 2002-02-01 um 12.33 schrieb Akim Demaille:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf Am Don, 2002-01-31 um 22.31 schrieb Alexandre Duret-Lutz:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf Am Don, 2002-01-31 um 17.27 schrieb Russ Allbery:
[...]
Why
Am Fre, 2002-02-01 um 14.34 schrieb Earnie Boyd:
Ralf Corsepius wrote:
BTW, I would appreciate the other autoconf and automake maintainers to
speak up, because apparently a reasonable discussion between Akim and me
doesn't seem to be possible anymore.
First let me say that IANAAM
Am Mon, 2002-02-04 um 10.31 schrieb Akim Demaille:
| Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
| Ralf Hi,
| Ralf Using the new AC_INIT syntax breaks AM_INIT_AUTOMAKE([no-define])
| Ralf rsp. its triple-argument form AM_INIT_AUTOMAKE(,,no):
|
| Ralf Given such kind
Am Die, 2002-02-05 um 09.45 schrieb Akim Demaille:
Akim == Akim Demaille [EMAIL PROTECTED] writes:
Ralf Example: Why should AC_INIT provide an email address or
Ralf PACKAGE_BUGREPORT? If a user really wants one, let him put a
Ralf AC_PACKAGE_ADDRESS([EMAIL PROTECTED]) or similar into his
Am Don, 2002-02-07 um 13.37 schrieb Tobias Hunger:
Stefan did complain about the lack of a way to tell private from public
macros, not about you changing private macros. What should a user of
autoconf do? Send a list of macros he wants to use to this list to
figure out which of them are OKto
Am Mon, 2002-02-04 um 22.58 schrieb Tom Tromey:
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf But I think, the actual cause for this issue is something different:
Ralf 3) AM_INIT_AUTOMAKE([no-define]) allows config-headers to be
Ralf exported, ie. to export and thereby globally
Am Mit, 2002-02-13 um 20.09 schrieb Henrique de Moraes Holschuh:
Currently we have some major breakage in Debian re. crosscompilation, and we
really would prefer to fix it only once (since it does mean changing all
packages that use autoconf, and that's quite a lot). That means we have
Am Don, 2002-02-14 um 16.17 schrieb Steve M. Robbins:
Hello,
In case Henrique's posting wasn't clear, the question is this: is
./configure --build=foo ...
different from
./configure --build=foo --host=foo ...
or not?
IMO, it is supposed not to be different.
In other
Am Mon, 2002-02-25 um 20.27 schrieb Zack Weinberg:
On Mon, Feb 25, 2002 at 07:32:30PM +0100, Akim Demaille wrote:
Zack == Zack Weinberg [EMAIL PROTECTED] writes:
Zack It may well be good enough. I cannot test it because (a) I have
Zack no access to any of the affected machines, and
Am Mon, 2002-03-11 um 00.12 schrieb Phil Edwards:
I'm one of the libstdc++-v3 people, and I've been making occasional
halfhearted attempts to move our configury to 2.5x. I had another go
this weekend, which led me to the autoconf mail archives and this thread.
So here's a status update:
Am Mon, 2002-03-11 um 19.10 schrieb Phil Edwards:
On Mon, Mar 11, 2002 at 03:28:29AM +0100, Ralf Corsepius wrote:
Am Mon, 2002-03-11 um 00.12 schrieb Phil Edwards:
AC_PROG_CC tries to do something in
the checking for C compiler default output section which fails (cannot
create
Am Fre, 2002-03-15 um 19.18 schrieb Scott McPeak:
Since this program doesn't use the C++ standard library, it doesn't test
whether that library is correctly installed.
I get about one report a month from someone who has trouble with my
deployed software because the C++ standard library
On Mon, 2005-05-02 at 10:31 +0200, Ralf Wildenhues wrote:
I have a question regarding systems with more than one ABI, specifically
x86_64. If you consider for example the Debian distribution which has a
x86_64 kernel, but a completely x86 userland, config.guess still gives
you
On Thu, 2005-05-26 at 09:59 +0900, Andre Caldas wrote:
Hello, Ed!
There are many things that are considered bad practice. There are
many things that are old deprecated ways to do things.
For example, using the file name configure.in is outdated. You should
use configure.ac.
On Fri, 2005-05-27 at 00:56 +0400, Ilya N. Golubev wrote:
Is
AC_ARG_WITH([cflags-warning],
dnl ...
)
a proper usage of `AC_ARG_WITH'? Or it violates autoconf conventions,
and some other ways of specifying these configuration options
(perhaps, `var=value' in command line) are more
On Thu, 2005-05-26 at 09:50 +0200, Stepan Kasal wrote:
Hello Ed,
This code seems to work fine, but am I missing something?
I guess that if you experience no problems, you can use the code.
The advice ``perform all tests unconditionally'' is a workaround
to fix current limitations of
On Fri, 2005-05-27 at 09:44 +0200, Stepan Kasal wrote:
Hi,
On Fri, May 27, 2005 at 08:17:58AM +0200, Ralf Corsepius wrote:
On Thu, 2005-05-26 at 09:50 +0200, Stepan Kasal wrote:
The advice ``perform all tests unconditionally'' is a workaround
to fix current limitations
On Fri, 2005-05-27 at 13:38 +0100, Keith MARSHALL wrote:
Stepan Kasal wrote:
It's hard to tell whether a macro calls AC_REQUIRE. (It can call it
indirectly.)
A real fix will be to use shell functions to reimplement AC_REQUIRE,
in autoconf-3.
Are you now saying that shell functions
On Fri, 2005-05-27 at 16:41 +0100, Keith MARSHALL wrote:
Bob Friesenhahn wrote, quoting me:
Yes, I see the logic of that. But, if configure has already
determined that the header file is not present, or at least not
usable, why would any user realistically want to do that?
The autoconf
On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
I think the best solution is to drop caching from programs.m4.
Only over my dead body ;-)
Caching was invented mainly for expensive tests which involve
calling a compiler, which can be really slow.
No, caching had been invented for faster
On Wed, 2005-06-01 at 13:45 -0400, Dan Manthey wrote:
On Wed, 1 Jun 2005, Ralf Corsepius wrote:
On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
I think the best solution is to drop caching from programs.m4.
Only over my dead body ;-)
Caching was invented mainly
On Fri, 2005-06-03 at 09:37 +0200, Stepan Kasal wrote:
Hello again,
I'm sorry that I post a followup to my own mail:
On Thu, Jun 02, 2005 at 09:04:06PM +0200, Stepan Kasal wrote:
On Wed, Jun 01, 2005 at 07:08:08PM +0200, Ralf Corsepius wrote:
No, caching had been invented for faster
On Fri, 2005-06-03 at 16:09 +0200, Stepan Kasal wrote:
Either autoconf should perform a clear cut, that is abandon caches
entirely,
No, I don't want that.
which means autoconf will be totally incompatible to any
former version of autoconf
_incompatible_ ?
If I remove caching from
On Sat, 2005-06-04 at 10:40 +0200, Gour wrote:
Hi!
AC_CONFIG_SUBDIRS([clisp-2.33.2])
but autoconf complains that clisp directory does not contain
configure.ac(in):
autoreconf-2.59: `configure.ac' or `configure.in' is required
IMO, you have tripped a bug in autoreconf.
I read about
On Thu, 2005-06-30 at 14:01 +0200, Stepan Kasal wrote:
Hello,
the autoconf manual says
You cannot assume the support of unset.
But no OS is mentioned.
[unset functions '# !' insufficiently documented]
IMO, there are good reasons for not doing so and for not given any
OS/shell
On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote:
Hi Stepan,
* Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST:
The macro has two uses:
1) in GNU make's configure.in
2) in Automake's AM_PROG_CC_C_O
How do you know nobody else uses it? It's published.
All
On Fri, 2005-07-01 at 15:23 +0200, Ralf Wildenhues wrote:
* Ralf Corsepius wrote on Fri, Jul 01, 2005 at 03:20:22PM CEST:
On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote:
* Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST:
The macro has two uses:
1) in GNU
On Tue, 2005-07-19 at 20:07 +0200, Stepan Kasal wrote:
Hi,
On Thu, Jul 14, 2005 at 12:19:26PM -0400, Sam Steingold wrote:
* David Boreham [EMAIL PROTECTED] [2005-07-14 08:42:46 -0700]:
Wouldn't it be easier to simply read the version number ?
...
isn't the whole idea of autoconf to
On Thu, 2005-07-21 at 07:29 +, [EMAIL PROTECTED]
wrote:
So my question is, is there a simple way to only include ($CFLAGS) when
compiling, and only ($LDFLAGS) when linking, NOT ($CFLAGS)?
Firstly, this is OT for this list. It's an automake question.
To answer your question: no.
Automake
On Wed, 2005-09-14 at 13:52 -0500, Bob Friesenhahn wrote:
On Wed, 14 Sep 2005, Peter Volkov Alexandrovich wrote:
The aim of scons is to replace gnu build system, but what are the weak
sides of gnu build system?
So far, scons is an exotic niche amongst other tools with almost no
relevant
On Mon, 2005-10-03 at 22:20 -0500, Brian Lloyd wrote:
I seem to have a problem with using autoreconf 2.59, and was wondering
if I misunderstood something.
Previously, I used
aclocal -I m4scripts
autoheader
autoconf
automake -ac
Now, it seems the include directory is ignored. Am I doing
On Tue, 2005-10-11 at 10:17 -0400, Sam Steingold wrote:
Hi Ralf,
thanks for your answer.
alas, I still have questions:
* Ralf Wildenhues [EMAIL PROTECTED] [2005-10-11 11:15:03 +0200]:
* Sam Steingold wrote on Mon, Oct 10, 2005 at 06:34:10PM CEST:
I am getting this:
sh config.status
On Wed, 2005-11-02 at 04:15 -0800, Ven Heusan wrote:
Hi all,
For my library package, I have written 'configure'
script with includedir variable as:
includedir='/usr/include/mylib'
My Makefile.in also has the same value for includedir
So that my header files can be installed in
On Wed, 2005-11-02 at 13:51 +0100, Stepan Kasal wrote:
Hello,
includedir='/usr/include/mylib'
I believe it's safer to use your own prefix.
Put this to your Makefile.am:
mylib_headersdir = /usr/include/mylib
Urghh,
... YOU are proposing to hard-code /usr/include?
Don't ever do
1 - 100 of 315 matches
Mail list logo
