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 w
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 anoth
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:
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 an
> "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>
| > 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 i
> "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
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.
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 install
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
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
> H
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 us
> "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 t
> "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?
> "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
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
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 o
17 matches
Mail list logo
