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
> "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
14 matches
Mail list logo
