Re: Add clang++ to AC_PROG_CXX

[Václav Haisman]

On 31 March 2016 at 04:30, Ruben Safir <address@hidden> wrote:
> On 03/16/2016 11:30 AM, Earnie wrote:
>> On 3/16/2016 4:02 AM, Václav Haisman wrote:
>>> On 15 March 2016 at 17:35, Paul Eggert <address@hidden> wrote:
>>>> On 10/04/2012 12:41 AM, Václav Zeman wrote:
>>>>>
>>>>> Does attached patch work for you?
>>>>
>>>>
>>>> Following up on this old thread, I applied the attached. In practice I
>>>> expect this doesn't matter much, as people configure with CC=clang when 
>>>> they
>>>> want clang. But we should at least fall back on clang if other C or C++ or
>>>> ObjC compilers do not work.
>>>
>>> Cool. I do not remember exactly if this was my motivation for the
>>> original submission but I believe this is still relevant for Cygwin
>>> where you can AFAIK install Clang and not install GCC (which creates
>>> the /usr/bin/cc to gcc). Without the patch, no compiler will be found
>>> even though Clang is present. This patch fixes the situation.
>>>
>>
>
>
> That is not a bug, it was a desired feature...

Huh. How is not finding a viable compiler when one is present a desired feature?

>
>
>
>> Rather than adding to this list of tools how about a configure.ac macro.
>>  Something named AC_REQUIRE_TOOL sounds correct and then AC_CHECK_TOOLS
>> also checks (or maybe an option to only check) the required tool.
>>
>> The problem I find with the list of defaults is that it can grow and the
>> more in the default list the longer the configure script will take.  If
>> I have a C package then I don't want to test for anything but a C
>> compiler.  I don't care about any of the others and testing for them
>> slows down the build process for my package.
>>
>> Yes I know I can set CC to be specific about which one but the users of
>> the package may not have that set or may have something else entirely
>> set.  My opinion is that the package maintainers need to be specific to
>> the tools required and punish them by not choosing any if none is set.
>> As a package maintainer I should also be able to set an option to ignore
>> the environment variables for these checks since the package may be
>> dependent on a specific named tool.
>>

-- 
VH