[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
25 Dec 2000 15:00:45 +0100
Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)
>>>>> "Pavel" == Pavel Roskin <address@hidden> writes:
>> I'm not sure I will be able to apply this patch. If it is
>> approved, don't hesitate to apply it, or to fix and apply it.
Pavel> At least some parts need to be applied.
You and Alexandre are good judges. Please, I'm soon leaving, may
I ask for a service? Could you adjust the patch to what emerges from
your debating, then snapshot 2.49c and put it on alpha, and send
an announcement? Don't hesitate removing the old betas. And
move configure.in to 2.49d.
>> +** AC_CHECK_FUNCS and AC_TRY_LINK_FUNC +I have still not
>> understood what's the difference between the two +which requires to
>> have two different sources: AC_LANG_CALL and +AC_LANG_FUNC_LINK_TRY
>> (which names seem to be inappropriate). +Wouldn't one be enough?
Pavel> The difference may be purely historical.
Yes, that's fairly possible. I have *very* bad memories of when I
merged all the various tricks of AC_CHECK_FUNC and AC_TRY_LINK_FUNC
etc. when aclang was created. And I do remember I gave on this
precise point: I felt completely incompetent.
It's not urgent, but really, we should either understand
why they have to be different, or really merge them.
>> -[AC_LANG_PROGRAM([m4_default([$1], address@hidden:@include "stdio.h"])],
>> +[AC_LANG_PROGRAM([m4_default([$1], address@hidden:@include <stdio.h>])],
Pavel> It's a separate issue and needs to be fixed regardless of the
Pavel> rest of the patch.
Well, if you want to spend more time applying this poor patch,
you're welcome :)
>> -m4_define([AC_LANG_SOURCE(C++)], -[#line __oline__ "configure"
>> -#include "confdefs.h" -#ifdef __cplusplus -extern "C" void exit
>> (int); -#endif -$1]) +m4_copy([AC_LANG_SOURCE(C)],
Pavel> I'm affraid that this change, once applied, will very soon need
Pavel> to be reverted. C and C++ are different enough to require
Pavel> different AC_LANG_SOURCE. I understand that we are not going to
Pavel> support C++ compilers that don't define __cplusplus.
I understand this. Nonetheless since we officially _try_ to
support CC=cxx, it's not that surprising they are so alike, and
will remain. But sure, maybe someday this approach will be proved
>> +# Some people use a C++ compiler to compile C. Since we use
>> `exit', +# in C++ we need to quote it. In case someone uses the
>> same compiler +# for both compiling C and C++ we need to have the
>> C++ compiler decide +# the declaration of exit, since it's the most
>> requiring environment. +_AC_COMPILE_IFELSE(address@hidden:@ifndef
>> + choke me address@hidden:@endif], + [_AC_PROG_CXX_EXIT_DECLARATION])
Pavel> That's not good. Every "configure" for pure C projects will
Pavel> contain C++ tests. Support C++ compilers in the C mode is a
Pavel> nice thing to have, but I doubt that it's really worth it when
Pavel> it comes to such workarounds.
Hm, I'm not sure I understand what you mean. No AC_PROG_CXX or
any other CXX macro will be triggered. We onlly test whether
the C compiler wants a proto for exit. If you dislike the name
which highlights the origin of this need, feel free to get rid
of _CXX_. I'd keep it though.
So what remain is a rather short macro, which is indeed based
on the assumption that all C++ compilers define __cplusplus, but
most of Autoconf does.