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
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 have the proper run-time
> library search paths encode
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
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 ju
> * 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 o
> "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
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 ti
| 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
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
| > 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
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-sett
--- 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 archite
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 know suggest this -
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 (
> -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,
> "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> 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 pa
> "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
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
ar
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
Bernard Dautrevaux wrote:
>
> Sure enough; I constantly forget this, probably because I *never* run
> configure manually but through a script in the build tree (and BTW type
> "./configure" instead of "make reconfigure" as my scripts usually
> automatically call aclocal/autoconf/automake)
Well, i
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"
However on systems with shared libraries you can't just "promote" a
linked program from /usr/bin to /bin -- you have to link it statically
-- i.e. the build has to know from the beginning that you're intending
to use the result at run-time from single-user mode.
Why is that? Don'
| 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
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 b
> "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 autoconf
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_PRO
30 matches
Mail list logo
