Correct?
Almost. I'd recommend more quoting, so that you can still change $prefix
at make time:
test "$libdir" = NONE && libdir='${prefix}/lib64'
Hi Eric, Tom,
both of you are wrong (at least for Autoconf 2.63). It ought to be
test "$libdir" = &#
On Tue, 21 Jul 2009, Ralf Wildenhues wrote:
* Peter Breitenlohner wrote on Mon, Jul 20, 2009 at 03:35:48PM CEST:
On Mon, 20 Jul 2009, Peter Breitenlohner wrote:
are there any plans that Automake supports ObjC++ (as implemented in
gcc-4.x)?
AFAIK nobody else is working on patches yet; they
without a released autoconf version providing the basics would be
rather awkward.
Regards
PeterFrom 8c1de4d15f1550956abace86ad6877e25dc05e9a Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner
Date: Tue, 21 Jul 2009 22:55:34 +0200
Subject: [PATCH] Implement and document Objective C++ support.
* lib/aut
On Wed, 22 Jul 2009, Peter Breitenlohner wrote:
There are no tests for ObjC, thus none for ObjC++ either. I think
eventually some such tests should be added.
Hi Eric,
I forgot: in order to verify the basic functionality (*) I have constructed
the attached tiny toy package.
(*)
(1
On Thu, 23 Jul 2009, Eric Blake wrote:
In general, I'm in favor of this patch, but you are right that it would be
nice to have some testsuite exposure to go along with it.
Hi Eric,
agreed. I'll think about some very basic tests for both ObjC and ObjC++.
However, there really isn't that much
On Thu, 23 Jul 2009, Eric Blake wrote:
Also, let's make sure we don't repeat the C++ mistake -
if no suitable ObjC++ compiler is found, please make sure OBJCXX is set to
no, not g++. (I didn't check if you did that).
Hi Eric,
although I remember having seen this (for C++) on the automa
On Tue, 15 Sep 2009, Eric Blake wrote:
According to Peter Breitenlohner on 7/22/2009 12:46 AM:
attached is a patch implementing autoconf support for ObjC++. As expected
this was extremely straightforward and only marginally intrusive.
I've applied it with only minor modifications (for
index.
Regards
Peter Breitenlohner From 79754666d92e4aa9325a41e3495a98c2c13c9580 Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner
Date: Wed, 14 Oct 2009 10:41:45 +0200
Subject: [PATCH] typo in cache variable index
Signed-off-by: Peter Breitenlohner
---
doc/autoconf.texi |2 +-
1 files chang
On Wed, 14 Oct 2009, Peter Breitenlohner wrote:
On Wed, 7 Oct 2009, Ralf Wildenhues wrote:
This has been done recently, for many cache variables. I failed to see
this message at that time (wrong Subject ;-) so didn't list you as bug
reporter.
attached is a tiny patch correcting a
rather unwanted
effect on multi-line values. This isn't really a problem except when
debugging complex macros.
I think the code, in general.m4 starting with AS_BOX([Output variables.]),
could easily be modified to first sort the variable names and insert their
values afterwards.
---
l.h],
[sed "s/@PACKAGE_VERSION@/$my_PACKAGE_VERSION/" avcall.h > tmp
mv -f tmp avcall.h],
[my_PACKAGE_VERSION=$PACKAGE_VERSION])
(the changed variable name is to avoid conflicts, may not be needed).
Regards
Peter Breitenlohner
___
Auto
figure.in would never look in the 64 bit directory.
About time to modify your configure.in as outlined above.
Regards
Peter Breitenlohner
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Make command line, i.e., `is reserved for the user'.
Regards
Peter Breitenlohner
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
in to configure.ac is, that
some future Autoconf version may cease to accept the 'bugward' compatible
old name. Everything else is philosophy/ideology.
Regards
Peter Breitenlohner
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/m
On Mon, 8 Mar 2010, Ralf Corsepius wrote:
IMHO, the only real reason to rename configure.in to configure.ac is, that
some future Autoconf version may cease to accept the 'bugward' compatible
old name.
Only partially.
Suffix rules/mime-types are the keywords you are looking for. Whether the
fi
[]dnl
LT_OUTPUT
m4_append([AC_LANG(C)],
[ac_link="./libtool --mode=link --tag=CC $ac_link"
])[]dnl
AC_PROVIDE_IFELSE([AC_PROG_CXX],
[m4_append([AC_LANG(C++)],
[ac_link="./libtool --mode=link --tag=CXX $ac_link"
])])[]dnl
AC_LANG(_AC_LANG)[]dnl
]) # _KPSE_USE_LIBTOOL
Re
efile, but
(except for srcdir) not necessarily defined at configure time.
if test "$sac_cv_cc_environment" = mingw32 ; then
CFLAGS="$CFLAGS -I${abs_srcdir}/win32/pthread ...
CFLAGS="$CFLAGS -I\${abs_srcdir}/win32/pthread ...
will do the right thing
ble in Makefile.
BTW: required flags as determined by configure should not go to CFLAGS,
because the user is entitled to use 'make CFLAGS=some_flags some_target'.
Using Automake they would typically go to AM_CFLAGS.
Regards
Peter Breitenlohner
will then
automatically apply to C as well as C++).
Regards
Peter Breitenlohner
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
t BIN_DIR/autoreconf line 484,
line 4.
autoreconf: Leaving directory `dialog'
===
Question:
(1) is there a better (more correct) way to achieve the same result?
(2) is there a way to avoid that warning.
Regards
Peter Breitenlohner
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
important point: we do want autoreconf to
recurse into subdirectories, just not into this particular one.
Regards
Peter Breitenlohner
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
quot;#if -1 >> 1 == -1" works, ...
Is it clear that the preprocessor must interpret -1 as signed??
Regards
Peter Breitenlohner
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
On Mon, 20 Dec 2010, Eric Blake wrote:
If a distro insists on shipping 64-bit libraries under /usr/lib64, then
it would be ...
This is not so much a "distro insisting" but rather the Linux file system
standard for bi-arch systems!
Regards
Peter Bre
/opt/newest_autotools_root/share/aclocal
But that didn't make any difference.
Hi Jim,
I have successfully used alternative autotools with (the analogue of)
export PATH=/opt/newest_autotools_root/bin:$PATH
Regards
Peter Breitenlohner
___
Autoco
use-case is TeX live with a total of about 70 configure
scripts and a very large number of common tests. Here -C gives a
considerable speed-up with prcatically no problems.
Thus I'd certainly object to a removal of the cache file.
Regards
Peter Breitenl
irst test fails. But with the cache feature, the second test
also fails.
The simplest and safest way is to do the second test with a different
symbol. Alternatively you could unset ac_cv_lib_bfd_bfd_openr (unless you
have an ancient broken shell).
Regards
Peter Breitenlohner
__
an
22.85 from Paul Vojta), or at least use that as a guide how to proceed?
$ (autoconf --version; automake --version) | grep ^auto
autoconf (GNU Autoconf) 2.61
automake (GNU automake) 1.10
IMHO it makes no sense to base new work on such ancient versions.
Regards
P
;],[CLANG_CC=1])],
[CLANG_CC=])
i.e., exactly one level of quotes for each macro argument. In addition it
might be safer to replace
test "$GCC" = yes
by
test "X$GCC" = Xyes
and similar.
Regards
Peter Breitenlohner
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
or 1.9.2. Tho output is attached.
BTW: The installed version of automake is 1.8.4
regards
Peter Breitenlohner <[EMAIL PROTECTED]>make -Ctests VERBOSE=1 TESTS='makej.test missing.test missing2.test' check
make: Entering directory
`/.th/thsrc/archive/gnu/automake/automake-1.9.3-bu
e/449: make check -- 3 tests fail
This one has, unfortunately, not been fixed in this version.
Please relay this to bug-automake@gnu.org and the other lists (where I am
not a member).
regards
Peter Breitenlohner <[EMAIL PROTECTED]>
___
Autoconf m
EACH([FOO], [one two three four etc], [
AC_CONFIG_SUBDIRS([FOO])
])
Peter Breitenlohner <[EMAIL PROTECTED]>___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
t should be VERY STRONGLY discouraged. After all, running
"reautoconf" may (does?) invoke aclocal.
[*] I'm not talking about m4 macros installed by some prerequisite package under
/usr/share/aclocal (or rather `aclocal --print-ac-dir`).
regar
from the source tree in
preference to those from the build tree
together with a tiny and IMHO uncontroversial patch solving this problem.
I am terribly disappointed that I never got any reaction and that this bug
is still present in the new release.
regards
Peter Breitenlohner <[EMAIL P
33 matches
Mail list logo
