>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
[...]
I think that by stealing CVS automake files you are putting
"beta-quality" content into autoconf.
Akim> +++ m4/missing.m4 2001/06/13 16:23:38
[...]
Akim> +AC_DEFUN([AM_MISSING_INSTALL_SH],
Akim> +[AC_REQUIRE([AM_MISSING_HAS_RUN]
> This is what I mean. Just a sample.
> Waiting for comments.
I really need opinions here! Alexandre? The point is to have all the
tests use the same set of core headers.
| >>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
| [...]
|
| I think that by stealing CVS automake files you are putting
| "beta-quality" content into autoconf.
|
| Akim> +++ m4/missing.m4 2001/06/13 16:23:38
|
| [...]
|
| Akim> +AC_DEFUN([AM_MISSING_INSTALL_SH],
| Akim> +[AC_REQU
> "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
I don't know where AC_ARG_VAR should be documented. Pavel, any idea?
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
Hi,
My general impressions after 1 day of autoconf 2.50 use.
- The backtrace facility is really a nice feature.
- "config.status much faster on most architectures"
but configure is slower. Here are the timings of gettext's configure:
autoconf 2.13: 23.0 sec real 14.2 sec user
aut
Dear Friend,
AS SEEN ON NATIONAL TV :
''Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 US Dollars expense one time''
THANKS TO THE COMPUTER AGE AND THE INTERNET!
=
BE A MILLIONAIRE LIKE OTHERS WITH
Hello,
Whether a option found by "configure"'s test is used (enabled) by
default is decided by the auther of the "configure" script, but I want
to override it as "no", that is, I want to use options which I
explicitly specify by "--enable-*".
This is needed when I create a (NetBSD's) package, in
> "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
| > 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
> "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>
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> "Nathan" == Nathan Neulinger writes:
Nathan> Would y'all consider extending the license exception to
Nathan> include the 'missing' script as well? (I'm referring to the
Nathan> exception that allows distributing autoconf support fil
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
14 matches
Mail list logo
