On Sep 7, 2000, Russ Allbery [EMAIL PROTECTED] wrote:
No, $(prefix) specifies the root of the package for whatever step you're
performing. --prefix as an argument to configure says to configure the
package with that root, $(prefix) in make says to build the package with
that root (and you
On Sep 8, 2000, Russ Allbery [EMAIL PROTECTED] wrote:
Alexandre Oliva [EMAIL PROTECTED] writes:
Unfortunately, it's not that simple, in general. For example, thinking
of libtool, on some platforms, shared libraries and programs that depend
on them have to be re-linked at install time to
Alexandre Oliva [EMAIL PROTECTED] writes:
On Sep 8, 2000, Russ Allbery [EMAIL PROTECTED] wrote:
I don't understand why this would be the case. Why can't the proper
run-time library search path be encoded when the binary or library is
built?
Because on certain platforms this just can't be
* What about other related Make variables, such as *dir?
Should they all be configure time options too?
Yes, and, in fact, they already are.
Not always. They are configure-time options in programs that
use Autoconf, and nowadays that may be most programs.
But *requiring* these
"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, make it
Richard Stallman [EMAIL PROTECTED] writes:
Eliminating the possibility of specifying them at make time would be a
bigger change and an incompatible one. I think we agree we should not
do that, but we should encourage people to specify these arguments
at configure time instead of make time.
| 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
"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 programs that
On Sep 8, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
"Richard" == Richard Stallman [EMAIL PROTECTED] writes:
Richard Not always. They are configure-time options in programs that
Richard use Autoconf, and nowadays that may be most programs. But
Richard *requiring* these options in the
Bernard Dautrevaux wrote:
BTW, having such an automatic default option shoudl be nice for almost all
tests; I know I can just "ac_c_bigendian=yes ./configure" but I never knows
the name of the config.cache variables, so "./configure --set-bigendian=yes"
coudl do the same.
a pre-setting
--- Akim Demaille [EMAIL PROTECTED] wrote:
This is also why I know suggest this --help:
| Installation directories:
| --prefix=PREFIX install architecture-independent files in PREFIX
|[/usr/local]
| --exec-prefix=EPREFIXinstall
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
Hello, Akim!
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 agree (in
-Original Message-
From: Guido Draheim [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 08, 2000 3:24 PM
To: Bernard Dautrevaux
Cc: [EMAIL PROTECTED]
Subject: adding platform-defaults [Re: AC_C_BIGENDIAN ... default
parameter]
Bernard Dautrevaux wrote:
BTW, having such
"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.
Absolutely. And
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?
I don't think so. The preprocessor is tested for different conditions.
Actually, what I was saying, is that my patch
"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 different
Pavel
Hi!
I'm starting to use autoconf now for our own developments, and found
two small problems when using autoconf in our development environment.
The first one is that (as we share a lot of data, including all the
$prefix/share tree) we choose not to install frozen M4 files as they are
Hi!
This patch makes autoconf prefer configure.gnu over configure when
configuring subdirectories; this is usefull if these subdirectories also
contain packages not using autoconf.
This patch originates from the GeekGadgets project
(http://www.ninemoons.com/GG/).
This is basically a resend of
Hi!
It is common practice to write:
--snip--
AC_ARG_ENABLE(.)dnl
bla bla bla
--snip--
While this works fine with autoconf 2.13, it fails with 2.49a - the configure script
contains syntax errors, ie the shell doesn't find the final "fi" anymore because
it doesn't consider "fiecho" or "fielse"
Hello, Akim!
Yes, this is a bad recommendation. And in fact you frightened me
Pavel, by current you mean 2.13, right? I could not find this horror
in the CVS documentation. But there is an answer to the above
statement:
Sorry to all :-(
"info --file autoconf.info" looks in /usr/info
"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.
On Fri, Sep 08, 2000 at 09:05:57AM -0400, Pavel Roskin wrote:
: I'll try to remove changequote()s from libtool.m4 as long as it remains
: compatible with Autoconf-2.13
I don't see how this can be a problem - it's strictly an m4 parse issue,
and the m4 parsing is the same, no matter which
Akim Demaille wrote:
Are there any reasons not to merge AC_PROG_CPP into AC_PROG_CC? I'm
..
I suppose the only real question is: are there any packages that use
AC_PROG_CPP but not AC_PROG_CC?
..
Can it make sense?
Well, I don't know about any autoconfizcated package using
AC_PROG_CPP
24 matches
Mail list logo
