| 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 l
> "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 deta
> "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 f
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 Aut
> "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 war
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,
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 w
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 0
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 PROTEC
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 "exec
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
: ac_objext=o
> "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.
| 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
> Ruslan Shevchenko writes:
> # RSSH_CHECK_SUNPROC_C([ACTION-IF-YES], [ACTION-IF-NOT])
I have added the macro to the autoconf archive a few moments ago;
thanks for the submission. I reformatted it quite a bit to make it
comply with the archive requirements, so you might want to get the
sour
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 chec
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 valu
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.st
> "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'
> "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 questi
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 n
> 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
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Is this macro really useful?
Personally I don't like it at all because it makes it possible to have
different behavior for two configures, which should never happen.
How about AU_DEFUN it to nothing?
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> 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''.
T
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Ohh yes, they have: they are getting rid of comments we should
Akim> make there way into configure, as if you were systematically
Akim> stripping all your objects.
s/we should make there/which should make their/
:@)
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],
s
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 definiti
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
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 vanishin
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 s
> "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 w
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> 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
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> 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
Thomas> your experience perhaps, but so far you've dec
> 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.
| > Akim Demaille writes:
|
| > 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 have 3 arguments# Hm, you should be three...
|
| Why woul
> 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 chos
> 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 a
--- 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
O
> "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
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/bu
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.
>
| > 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 re
> "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 insta
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 ca
> 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 -t
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 fi
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 re
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 ada
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
> -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 poi
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 (withou
> 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
> |
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 experience. I've seen .C
a few times; I'v
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 you
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 make install prefix=/foo
> unless you wan
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
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 Un
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 separa
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_H
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
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 easie
On Jul 19, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> Has anyone come up a reason why setting the ${prefix} and ${exec_prefix}
> variables at the top of ./configure would be bad?
I think the point is to be able to tell whether it was the user who
chose /usr/local or if it's going to be used ju
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 t
> 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}.
> T
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 sev
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 ${p
--- Russ Allbery <[EMAIL PROTECTED]> wrote:
> 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 d
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
Mo> echo "prefix is \"$prefix\""
Mo> echo "exec_prefix is \"$exec_prefix\""
Mo> % ./configure --prefix=/tmp
Mo> ...
Mo> prefix is "/tmp"
Mo> exec_prefix is "NONE"
Mo> This should print:
Mo> % ./configure --prefix=/tmp
Mo> ...
Mo> prefix is "/tmp"
Mo> exec_prefix is "/tmp"
That's where we disagr
%% 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 te
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 packa
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 h
> 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
> Akim Demaille writes:
>
> > But precisely because of your needs, don't you need an output variable
> > or something instead of the CPP symbol?
>
> Certainly so.
And then, for full functionality, automake should use that variable
in generating rules, right?
.c.o:
$(CC) $(CFLAGS) ..
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
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
Martin> .c.o: $(CC) $(CFLAGS) ... @CC_C_O@ $<
Tom> This won't be sufficient. Automake will need more information.
Akim> Such as?
Merely having a subst like that isn't good enough because automake
still has to support the general case. So instead automake would want
some value it can check and
> "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
87 matches
Mail list logo
