Akim Demaille wrote:
| How about merging AC_PROG_CPP and AC_PROG_CC together?
|
| What's the point of keeping the two of them?
| * Some tools (eg. imake) apply cpp as macro-processor, even if cc is
| not available on a particular installation. Other tools might want
|
Pavel == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel This brings an interesting idea. How about AC_LANG(none)? In
Pavel this mode any checks involving compilers will be
Pavel disallowed. AC_PROG_CPP will default to cpp in $PATH with
Pavel /lib/cpp being the fallback.
I have another question
Hello, Akim!
My feeling is that CPP, here, was used only for performance issues.
Yes, this was my point. The whole idea of dealing with preprocessor was to
speed up checks for tests, _not_ to find CPP that the user should run
directly.
However, it was abused later. Header checks were used to
Pavel == Pavel Roskin [EMAIL PROTECTED] writes:
How about merging AC_PROG_CPP and AC_PROG_CC together? What's the
point of keeping the two of them?
Pavel My concern is compatibility. There is no real reason to test
Pavel for one but not the other, but if we go ahead and merge those
Pavel
| How about merging AC_PROG_CPP and AC_PROG_CC together?
|
| What's the point of keeping the two of them?
| * Some tools (eg. imake) apply cpp as macro-processor, even if cc is
| not available on a particular installation. Other tools might want
| to apply these tools even if
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf This thought however raises another question: Why does
Ralf AC_PROG_CPP exist at all?
Ralf I would assume: * Some autoconf-users wanted to use CPP without
Ralf CC (I have even seen cases were a host's native cpp have been
Ralf applied to
Hello, Akim!
Pavel If you feel that you can handle it feel free to merge. It
Pavel should be done earlier or later anyways.
So you share my opinion?
I share your opinion that AC_PROG_CPP and AC_PROG_CC should be merged
eventually. Whether it should be done before Autoconf-2.51 is another
Pavel Roskin wrote:
Hello, Ralf!
Hi Pavel,
How about merging AC_PROG_CPP and AC_PROG_CC together?
What's the point of keeping the two of them?
* Some tools (eg. imake) apply cpp as macro-processor, even if cc is
not available on a particular installation. Other
Hello, Ralf!
[I'm dropping [EMAIL PROTECTED] since the discussion concentrates on
Autoconf.]
Testing the preprocessor without
testing for a working compiler is reasonable, but in many cases $CC -E
is preferred over /lib/cpp, so it's a good idea to test for the compiler
anyways.
Hmm, my
Hello, Ralf!
How about merging AC_PROG_CPP and AC_PROG_CC together?
What's the point of keeping the two of them?
* Some tools (eg. imake) apply cpp as macro-processor, even if cc is
not available on a particular installation. Other tools might want
to apply these tools
Pavel == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel I have noticed Automake testsuite failures in distname.test,
Pavel subobj5.test and subobj6.test on OpenBSD 2.7 with the CVS head
Pavel versions of Autoconf and Automake.
What's the status of this issue, Pavel?
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan This sounds familiar to me - I think I ran in to the same
Harlan problem under FreeBSD on a configure.in script that only
Harlan wanted to find the X directories (header and libs). I had to
Harlan specify AC_PROG_CC to solve the problem.
Hi, Akim!
Pavel I have noticed Automake testsuite failures in distname.test,
Pavel subobj5.test and subobj6.test on OpenBSD 2.7 with the CVS head
Pavel versions of Autoconf and Automake.
What's the status of this issue, Pavel?
Nothing has changed. The problem persists. There is a useful
Akim Demaille wrote:
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan This sounds familiar to me - I think I ran in to the same
Harlan problem under FreeBSD on a configure.in script that only
Harlan wanted to find the X directories (header and libs). I had to
Harlan specify
Pavel == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel I don't know whether Autoconf should be more robust or Automake
Pavel should take less (or more?) hackerish approach.
Probably the former.
Pavel Since Autoconf-2.50 has been released, it would be fair to drop
Pavel support for
Hello!
First of all, sorry for cross-posting, but as you will see it's hard to
decide whether Automake or Autoconf is guilty.
I have noticed Automake testsuite failures in distname.test, subobj5.test
and subobj6.test on OpenBSD 2.7 with the CVS head versions of Autoconf and
Automake.
It turns
This sounds familiar to me - I think I ran in to the same problem under
FreeBSD on a configure.in script that only wanted to find the X directories
(header and libs). I had to specify AC_PROG_CC to solve the problem.
H
17 matches
Mail list logo
