| On Wed, 12 Jul 2000, Peter Eisentraut wrote:
| Alexandre Oliva writes:
|
|What about systems that don't have a `cc' but only a `gcc' or whatever
|else?
|
| The user would have to set CC_FOR_BUILD. But see below:
|
|In the future, it may be extended to look for gcc if it
"Jerome" == Jerome G Benoit [EMAIL PROTECTED] writes:
Generally the answer is "use sed". Do you really mean to assign to
"$bb"? I'm suprised that works. In that case you might need
sed+eval.
Jerome Can you please be more explicit/verbose ?
Actually you should give more details :)
What
"Lars" == Lars J Aas [EMAIL PROTECTED] writes:
Mo I ran into a problem like the one you describe. It seems : that
Mo the CVS version of autoconf does not work with : VC++ at all.
Lars This is *bad* news for me, but probably not for Autoconf
Lars development, as I'll have to work on fixing
On 19 Jul 2000, Akim Demaille wrote:
"Lars" == Lars J Aas [EMAIL PROTECTED] writes:
Mo I ran into a problem like the one you describe. It seems : that
Mo the CVS version of autoconf does not work with : VC++ at all.
Lars This is *bad* news for me, but probably not for Autoconf
Lars
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo Forgive my ignorance, but where would I find "patch 25-*"?
It's in [EMAIL PROTECTED] I thought you subscribed :(
See http://sources.redhat.com/ml/autoconf-patches/2000-07/msg00366.html.
| % ./autogen.sh
| autoheader: src/config.h.in is unchanged
| configure.in:23: warning: AC_CANONICAL_BUILD invoked multiple times
|
| (line 23)
| dnl Set up host checks using config.sub and config.guess.
| AC_CANONICAL_HOST
| AC_CANONICAL_BUILD
|
| Any ideas why autoconf now generates a
On Wed, Jul 19, 2000 at 12:24:08PM +0200, Akim Demaille wrote:
: "Lars" == Lars J Aas [EMAIL PROTECTED] writes:
:
: Mo I ran into a problem like the one you describe. It seems : that
: Mo the CVS version of autoconf does not work with : VC++ at all.
:
: Lars This is *bad* news for me, but
On Wed, Jul 19, 2000 at 01:43:58PM +0200, Lars J. Aas wrote:
: On Wed, Jul 19, 2000 at 12:24:08PM +0200, Akim Demaille wrote:
: : Mo, Lars, could you give a look at the patch 25-* and see if it works?
: :
: : I don't recall well why we recently chose .cc for C++. ISTR it was
: : because before
AFAIK .cpp is the most portable C++ extension. The Mozilla and ACE (hi
Ossama:) people settled on it for that reason.
It is something akin to slow torture to get VC++ using .cc (requires
registry mangling etc). BCB 4 won't use .cc at all.
Alex.
Lars J. Aas writes:
On Wed, Jul 19, 2000 at
How about this?
I don't have good answers yet to provide wrt .obj, maybe you should
try to set it by hand in configure.in just to see if it works. We
will address this second issue later (note that ./configure
ac_objext=obj should be enough).
Index: ChangeLog
from Akim Demaille [EMAIL
I have run into something that seems really strange to me.
Autoconf will subst @prefix@ and @exec_prefix@ into a
Makefile, but while ./configure is actually running they
are not set. Here is a minimal example.
% cat configure.in
AC_INIT(foo.c)
AC_PROG_CC
echo "prefix is \"$prefix\""
echo
On Wed, Jul 19, 2000 at 02:11:43PM +0200, Akim Demaille wrote:
: How about this?
:
: I don't have good answers yet to provide wrt .obj, maybe you should
: try to set it by hand in configure.in just to see if it works. We
: will address this second issue later (note that ./configure
:
"Lars" == Lars J Aas [EMAIL PROTECTED] writes:
Lars On Wed, Jul 19, 2000 at 02:11:43PM +0200, Akim Demaille wrote: :
Lars How about this? : : I don't have good answers yet to provide
Lars wrt .obj, maybe you should : try to set it by hand in
Lars configure.in just to see if it works. We :
On Wed, Jul 19, 2000 at 02:33:25PM +0200, Akim Demaille wrote:
: "Lars" == Lars J Aas [EMAIL PROTECTED] writes:
: Lars It got further (when I added ac_objext=obj - without it, all the
: Lars extension tests failed of course), but stopped again on a
: Lars "conftest.cc" file when it checked if
On 19 Jul 2000, Akim Demaille wrote:
| Does anyone else find that rather odd? I would like to
| be able to set vars that I am going to subst based on
| ${prefix} and ${exec_prefix}, but it seems that nasty
| hacks like the following are required in my configure.in.
"" is a valid value for
On 19 Jul 2000, Akim Demaille wrote:
| I have run into something that seems really strange to me.
| Autoconf will subst @prefix@ and @exec_prefix@ into a
| Makefile, but while ./configure is actually running they
| are not set. Here is a minimal example.
they're generated in config.status
"Lars" == Lars J Aas [EMAIL PROTECTED] writes:
Lars You're right - that wasn't directly from autoconf. It's an
Lars AC_TRY_COMPILE we set up in a custom macro that fails, and
Lars ac_ext is ".cc" at that point.
!!! If you applied all the patch I sent, it should not be .cc. I
don't know
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo Why can't we set prefix to /usr/local and exec_prefix to ${prefix}
Mo unless it differs from prefix? It is getting set in ./configure it
Mo is just a matter of when.
The only place were we rely on it is
# AC_PREFIX_PROGRAM(PROGRAM)
#
"Thomas" == Thomas E Dickey [EMAIL PROTECTED] writes:
./configure prefix=toto
make prefix=/usr/local
This sucks too :( IMHO, it should not be possible, and maybe it is
now obsoleted by DESTDIR?
Thomas those are two entirely different sets of variables
Yep, my question is ``was the
On 19 Jul 2000, Akim Demaille wrote:
Yep, my question is ``was the requirements over being able to specify
prefix etc. at make time a first weak attempt to achieve a goal which
is now properly solved with DESTDIR''.
$prefix may result in compiled-in paths,
$DESTDIR should not
but there's no
Ruslan Shevchenko writes:
| I generally favour "dnl" over "#", because "#" is not a comment
| delimiter in m4.
It is, it definitely *is*. In m4 there is a difference between
comments and text you get rid of which. Comments are introduced with
`#':
~ace % m4
ac_ext is set to "cc" right after the objext test is done.
Lars J
##
The inline for-loop macro:
AC_DEFUN([SIM_COMPILER_INLINE_FOR], [
AC_PREREQ([2.14])
AC_CACHE_CHECK(
[whether the C++ compiler handles inlined loops],
Dear Autoconf users,
this mail is going to the autoconf mailing list for the benefit of all
readers. An additional blind carbon copy has been sent to all authors
of macros contained in the archive that were affected by the change.
It has been recommended to enforce the macro name in all
OK, the patch is broken: at some places it uses ac_cv_lang_Cpp_inext,
and ac_cv_Cpp_inext. You should fix the occurrences of the latter
into the former.
Akim Demaille writes:
I'm sorry, but your argument makes no sense to me. I suppose it
also means I should not use the pattern /* in sh because it might
be a C comment? Or the converse?
The difference is that when I write "dnl some text" in an m4 file, it
is ignored as a comment no matter
On 19 Jul 2000, Akim Demaille wrote:
"Thomas" == Thomas E Dickey [EMAIL PROTECTED] writes:
Thomas (I'm told that people do reuse the makefiles without rerunning
Thomas configure)
This is my question :) My point is that the number of packages for
which this works is vanishingly small.
On 19 Jul 2000, Akim Demaille wrote:
Most comments are to be kept in configure, but comments about M4
constructs. Experience demonstrates that people are dnling out
your experience perhaps, but so far you've declined to cite examples
sufficient to determine if it's an occasional problem or
"Peter" == Peter Simons [EMAIL PROTECTED] writes:
Akim Demaille writes:
I'm sorry, but your argument makes no sense to me. I suppose it
also means I should not use the pattern /* in sh because it might
be a C comment? Or the converse?
Peter The difference is that when I write "dnl some
Akim Demaille writes:
~ace % m4nostromo 15:18
define(`count', `I have $# arguments')
count(a, b, c)dnl Hm, you should be three...
I have 3 argumentsdnl Hm, you should be three...
count(a, b, c)# Hm, you should be three...
I
I don't know if moving to .cpp is safe everywhere. Hence this patch.
VC++ understands an option `-Tp' (or `-TP') that tells the file is a C++
file no matter what its extension is. `-Tp' must be followed by the
file name immediately (as in `-Tpfoo.cxx', no space allowed), `-TP'
applies to all
Tom, have you taken a look at the source file extension problem? It
seems we don't know what sane extension we could use to compile C++
source files. For instance VC++ rejects .cc.
AFAIK, there is no one extension that all C++ compilers will be happy
with. After a bit of research we chose
Akim Demaille writes:
dnl is still useful: it documents M4 constructs.
# is useful: it document Autoconf issues.
I see your point. I think we settle for a compromise and allow both
forms and explicitely mention both forms on the autoconf archive web
site. Then we can let the macro authors
--- Akim Demaille [EMAIL PROTECTED] wrote:
IOW, what's the point of being able to change prefix at make time?
Why not just at configure?
How about the scenario of:
configure --prefix=/usr
make all
make install prefix=/usr/stow/mypackage.mj.mn.p
cd /usr/stow
stow mypackage.mj.mn.p
OR:
"Peter" == Peter Simons [EMAIL PROTECTED] writes:
Akim Demaille writes:
dnl is still useful: it documents M4 constructs.
# is useful: it document Autoconf issues.
Peter I see your point. I think we settle for a compromise and allow
Peter both forms and explicitely mention both forms on the
On Wed, Jul 19, 2000 at 03:14:13PM +0200, Akim Demaille wrote:
IOW, what's the point of being able to change prefix at make time?
Why not just at configure?
make prefix=/path/to/install install
Ie, you want to install into a different area then your built for.
Or, you are developing code/bug
Lassi A. Tuura:
VC++ understands an option `-Tp' (or `-TP') that tells the file is a C++
file no matter what its extension is. `-Tp' must be followed by the
If we can find similar options for all "relevant" compiler systems,
IMO we really should avoid messing with source file extensions.
--- Peter Simons [EMAIL PROTECTED] wrote:
True, using "dnl", the comments won't make it into the generated
configure script, but my guess is that hardly any user ever really
looks into the shell scripts. As long as the comments are contained in
the m4 source, this seems to suffice.
I
| IOW, what's the point of being able to change prefix at make time?
| Why not just at configure?
|
|
| How about the scenario of:
|
| configure --prefix=/usr
| make all
| make install prefix=/usr/stow/mypackage.mj.mn.p
| cd /usr/stow
| stow mypackage.mj.mn.p
I didn't know stow would rely
"Mike" == Mike Castle [EMAIL PROTECTED] writes:
Mike On Wed, Jul 19, 2000 at 03:14:13PM +0200, Akim Demaille wrote:
IOW, what's the point of being able to change prefix at make time?
Why not just at configure?
Mike make prefix=/path/to/install install
Mike Ie, you want to install into a
Akim The reason why you can't depend upon this is that somewhere,
Akim IMHO, it is just wrong to expect make prefix=/foo to work
Akim properly. Specifying prefix etc. is a job for configure, not
Akim make.
That may be, but there is a long tradition of supporting this.
Tom
In message [EMAIL PROTECTED], Earnie Boyd writes
I just want to add that seeing the comments in the generated scripts is an
added benefit to the newbie trying to learn what's happening. It more clearly
shows how we get from foo.in to foo.sh and makes the process easier to
assimilate.
It can
I'd be grateful if you detail a bit about this compiler's peculiarities.
To date, xlf is still my favourite, perhaps Microsoft can beat him... :-)
I don't work with M$ systems at all (lucky me!), so I have no idea.
df cannot do any form of useful preprocessing; this build system uses
gcc
Dear Lassi A. Tuura, you wrote on Today:
$ cat foo.f90
SUBROUTINE foo
RETURN
END
$ xlf -qsuffix=f=f90 foo.f90
xlf: 1501-218 file foo.f90 contains an incorrect file suffix
ld: 0711-715 ERROR: File foo.f90 cannot be processed.
The file must be an object file, an
On 19 Jul 2000, Peter Simons wrote:
Dear Autoconf users,
this mail is going to the autoconf mailing list for the benefit of all
readers. An additional blind carbon copy has been sent to all authors
of macros contained in the archive that were affected by the change.
It has been
On Wed, 19 Jul 2000, Peter Simons wrote:
True, using "dnl", the comments won't make it into the generated
configure script, but my guess is that hardly any user ever really
looks into the shell scripts. As long as the comments are contained in
the m4 source, this seems to suffice.
I read
Could you perhaps consult your manual and find out whether that
old version had an equivalent to the -qsuffix option?
I couldn't find any mention, that's why I asked :-/ Sorry...
Cheers,
//lat
--
The reasonable man adapts himself to the world; the unreasonable
one persists in trying to
On Wed, 19 Jul 2000, Earnie Boyd wrote:
--- Peter Simons [EMAIL PROTECTED] wrote:
True, using "dnl", the comments won't make it into the generated
configure script, but my guess is that hardly any user ever really
looks into the shell scripts. As long as the comments are contained in
-Original Message-
From: Akim Demaille [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 19, 2000 5:04 PM
To: [EMAIL PROTECTED]
Cc: Thomas E. Dickey; Mo DeJong; [EMAIL PROTECTED]
Subject: Re: Why does ./configure not set prefix and exec_prefix?
| IOW, what's the point of
Dear Lassi A. Tuura, you wrote on Today:
I'd be grateful if you detail a bit about this compiler's peculiarities.
To date, xlf is still my favourite, perhaps Microsoft can beat him... :-)
df cannot do any form of useful preprocessing; this build system uses
gcc -traditional (without
That's neither exceptional nor really problematic. I am confident
the new Fortran/cpp macros I am developing will handle this.
Nice! I'd like to see those when you are done. For us, gcc does the
preprocessing just fine; df can't do any. IIRC it has the `INCLUDE'
form, but that's no use for
--- Akim Demaille [EMAIL PROTECTED] wrote:
| IOW, what's the point of being able to change prefix at make time?
| Why not just at configure?
|
|
| How about the scenario of:
|
| configure --prefix=/usr
| make all
| make install prefix=/usr/stow/mypackage.mj.mn.p
| cd /usr/stow
Akim Demaille [EMAIL PROTECTED] writes:
The only place were we rely on it is
# AC_PREFIX_PROGRAM(PROGRAM)
# --
Is this macro really useful?
The primary place I remember it being used is in gzip. The intention is
to get gzip to install in the same place as your
On 19 Jul 2000, Russ Allbery wrote:
Akim Demaille [EMAIL PROTECTED] writes:
* Running @samp{make install} with a different value of @code{prefix}
* from the one used to build the program should @var{not} recompile
* the program.
This is all I wanted to know. Just don't use
On 19 Jul 2000, Russ Allbery wrote:
Akim Demaille [EMAIL PROTECTED] writes:
I don't recall well why we recently chose .cc for C++. ISTR it was
because before we used `.C' which is not a good choice in case
insensitive environments.
.cc is very standard for C++ files on Unix in my
Hello, Russ!
DESTDIR is completely unusable for this situation because DESTDIR requires
a complete replication of your final file system structure under the
DESTDIR root, which isn't how this normally works. DESTDIR is more
intended for doing things like installing packages into a separate
On Jul 19, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
| % ./autogen.sh
| autoheader: src/config.h.in is unchanged
| configure.in:23: warning: AC_CANONICAL_BUILD invoked multiple times
|
| (line 23)
| dnl Set up host checks using config.sub and config.guess.
| AC_CANONICAL_HOST
|
Mo DeJong [EMAIL PROTECTED] writes:
I think the common case for almost everyone is "./configure ; make
install"
Doing an install into a different directory than you configured for may
be possible with some packages, but I don't think it is the common case.
Yes, but I do it 100% of the
Pavel Roskin [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] writes:
DESTDIR is completely unusable for this situation because DESTDIR
requires a complete replication of your final file system structure
under the DESTDIR root, which isn't how this normally works. DESTDIR
is more
Mo Has anyone come up a reason why setting the ${prefix} and
Mo ${exec_prefix} variables at the top of ./configure would be bad?
You want the directory variable to be defined in terms of each other
in the Makefile if the user does not override them. That makes the
"make prefix=..." trick easier
On Wed, 19 Jul 2000, Tom Tromey wrote:
Mo Has anyone come up a reason why setting the ${prefix} and
Mo ${exec_prefix} variables at the top of ./configure would be bad?
You want the directory variable to be defined in terms of each other
in the Makefile if the user does not override them.
Sure. I want to install autoconf. autoconf should look for all of its
private files in /usr/pubsw/lib/autoconf. autoconf will be located in
/usr/pubsw/bin/autoconf. In order for that to happen, autoconf has to
*install* into /afs/.ir/pubsw/Development/autoconf-2.13/share/{bin,lib}.
Those
Pavel Roskin [EMAIL PROTECTED] writes:
Well, autoconf is not a good example. It only uses directories derived
from $prefix for installation. It doesn't use /etc/ and /var. You must
be doing more insane tricks to handle packages that do.
Thankfully the number of packages that are that
Mo DeJong [EMAIL PROTECTED] writes:
% ./configure --prefix=/tmp
...
prefix is "/tmp"
exec_prefix is "NONE"
This should print:
% ./configure --prefix=/tmp
...
prefix is "/tmp"
exec_prefix is "/tmp"
and then subst @exec_prefix@ with ${prefix}.
Why not just have it print ${prefix}?
--
Russ I think that make install prefix= should continue to work so
Russ that we don't have to resort to ugly hacks like that to force
Russ DESTDIR into doing things it wasn't designed for originally.
If the prefix= trick goes away you can always hack install-sh to do
almost anything.
Tom
%% Russ Allbery [EMAIL PROTECTED] writes:
ra DESTDIR is unusable for this purpose, because DESTDIR would attempt to
ra install into /afs/.ir/pubsw/Development/autoconf-2.13/usr/pubsw/bin.
ra That's wrong. That's not the structure of our package volumes. And
ra there's no way of telling
Paul D Smith [EMAIL PROTECTED] writes:
%% Russ Allbery [EMAIL PROTECTED] writes:
ra DESTDIR is unusable for this purpose, because DESTDIR would attempt to
ra install into /afs/.ir/pubsw/Development/autoconf-2.13/usr/pubsw/bin.
ra That's wrong. That's not the structure of our package
Tom Tromey [EMAIL PROTECTED] writes:
Russ I think that make install prefix= should continue to work so
Russ that we don't have to resort to ugly hacks like that to force
Russ DESTDIR into doing things it wasn't designed for originally.
If the prefix= trick goes away you can always hack
Nope, I think this is a case where we should mandate an extension.
For instance, I'm very much for .f77 for Fortran 77, and not .f, so
that for instance Automake knows what is the compiler to run if there
is F77, F90 and the preprocessed variations.
The de-facto standard seems to be that
Martin And then, for full functionality, automake should use that
Martin variable in generating rules, right?
Martin .c.o:
Martin $(CC) $(CFLAGS) ... @CC_C_O@ $
This won't be sufficient.
Automake will need more information.
Tom
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
Martin And then, for full functionality, automake should use that
Martin variable in generating rules, right?
Martin .c.o: $(CC) $(CFLAGS) ... @CC_C_O@ $
Tom This won't be sufficient. Automake will need more information.
Such as?
Tom, have you
Akim Same for C++, Automake should, IMHO, require a single extension.
Instead of that we can just document the portable one. Being forced
to rename all the files in your project when you know it will never be
a problem for you would be annoying.
For instance, libgcj uses ".cc". We don't care
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
Akim What would Automake (or missing) need to know?
Tom Whether the compiler can support the extensions actually in use
Tom by the program. This is an ugly problem because it involves
Tom feedback from Makefile.am to configure.
Nope, I think this
72 matches
Mail list logo
