Re: Add clang++ to AC_PROG_CXX

[Russ Allbery]

Ruben Safir <address@hidden> writes:
>> On 3/16/2016 4:02 AM, Václav Haisman wrote:

>>> 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...

I'm not sure who you are or what your role in Autoconf development is, or
why you feel empowered to speak for the project and its goals, but
Autoconf has always supported *proprietary* compilers (let alone free
software compilers that use BSD-style unrestrictive licenses).

This comes directly from its pragmatic role as a tool to help people
deploy free software on their local systems, even if those systems are
mostly not free software.  Many, many people have installed Autoconf-built
software on proprietary operating systems as their first step in using
free software, and have gone on to use more and more free software and
even free operating systems.  I'm one of those people.  Without the
ability to install free software on proprietary systems with proprietary
tools, those people might not have ever considered free software.

Given the decline in proprietary UNIX platforms, this goal may not be as
common today, but I think it clearly still exists.  While proprietary UNIX
platforms are not as common on servers (largely due to the amazing success
of free software), Mac OS X is very widely used and plays a comparable
ecosystem role.

It might make strategic sense in some cases to decline to cooperate with
proprietary software (and maybe even free but not copyleft software,
although I'm much more dubious there) as a way of solidifying the
strategic advantage of free software and making our community stronger.
But if it does, it would be in a place where free software provides some
compelling user benefit over proprietary software that proprietary
software would like to copy.  Apart from us all, the sort of people who
enjoy reading mailing lists about build systems, the build system for a
piece of software is rarely, if ever, the piece that offers that sort of
compelling benefit.  Building a piece of software so that you can try it
is not the place where you fall in love with it; rather, it's a necessary
evil to get to the interesting bit of actually using the software.

Given that, I believe the right *ideological* role for Autoconf, in full
cooperation with the FSF's principles and ideals, is to make it as easy as
possible to get free software working on any platform, even proprietary
platforms, because that's how we get our foot in the door, and that's how
we get more people using free software.  Let's save strategic lack of
cooperation for some other area where the benefits for users are actually
compelling.

-- 
Russ Allbery (address@hidden)              <http://www.eyrie.org/~eagle/>