Ruben Safir <ruben@xxxxxxxxxxxx> 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 (eagle@xxxxxxxxx) <http://www.eyrie.org/~eagle/> _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
