Re: Add clang++ to AC_PROG_CXX

[Russ Allbery]

Ruben Safir  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 (ea...@eyrie.org)  

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Dropping support for all non-free tools (was: Add clang++ to AC_PROG_CXX)

[Dustin Laurence]

On 03/31/2016 12:52 PM, Jeffrey Walton wrote:

> What purpose does it serve to alienate a majority of the users from
> whom you need support to achieve your goals? That seems like it will
> take a bad situation (lack of overwhelming support for FSF ideals) and
> make it worse (aggravate more developers and users, which nets you
> less support).



As a specific example of the above, how does it further the FSF's goals
to provide further impetus for competing tools, e.g. CMake?

The FSF already has exceptions for certain pieces of infrastructure;
bison's special license for generated code and the LGPL, for example.
Crudely speaking, those exist for code which is not "the only game in
town," which changes the cost-benefit analysis.  Leverage depends on the
availability of alternatives, and strategy depends on available leverage.

Unfortunate or not, GCC is no longer the only "freely available"
compiler, and it seems somewhere between foolish and absurd to try to
put that cat back in the box with autoconf.  Similarly, autoconf isn't
the only "freely available" quality build tool, and so I don't think
trying to disadvantage clang is going to do much more than providing one
more reason for people to consider using a different tool.  The usual
purity-based arguments to the contrary amount to arguing that the best
move in chess is always the most aggressive one.

Using the leverage when available is a plausible strategy--giving up
leverage without compensating advantage is not.  Were re-boxing the
clang cat possible, it would be through improving GCC's competitive
posture so as to retain leverage.  It certainly won't be done via clever
choices of defaults in other tools.

That said, purity is a more seductive argument than pure pragmatism, and
no opinion is going to change on this topic.  Why am I even posting?



Dustin


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Dropping support for all non-free tools (was: Add clang++ to AC_PROG_CXX)

[Jeffrey Walton]

On Thu, Mar 31, 2016 at 1:22 PM, Ruben Safir  wrote:
> On Thu, Mar 31, 2016 at 07:13:18PM +0200, Václav Haisman wrote:
>> On 31.3.2016 18:46, Ruben Safir wrote:
>> > On 03/31/2016 12:31 PM, Jeffrey Walton wrote:
>> >> viable compiler
>> >
>> > It will be viable when they release it under the GPL3.
>>
>> In that case, I am waiting for you to present and get through patches
>> that remove aCC, cl.exe, FCC, KCC, RCC, xlC_r, and xlC as well as clang
>> from the code.
>>
>
> That is irrelevant to the issue being address.  Just because something stupid
> was done in the past doesn't mean that it should be stupidly be done in the
> present.

That sword cuts both ways

The FSF has worthy goals, like ensuring user freedoms. There's a
reason the principals don't dominate the landscape. It seems to
indicate a problem with the approach or execution.

What purpose does it serve to alienate a majority of the users from
whom you need support to achieve your goals? That seems like it will
take a bad situation (lack of overwhelming support for FSF ideals) and
make it worse (aggravate more developers and users, which nets you
less support).

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Add clang++ to AC_PROG_CXX

[Ruben Safir]

On Thu, Mar 31, 2016 at 07:13:18PM +0200, Václav Haisman wrote:
> On 31.3.2016 18:46, Ruben Safir wrote:
> > On 03/31/2016 12:31 PM, Jeffrey Walton wrote:
> >> viable compiler
> > 
> > It will be viable when they release it under the GPL3.
> 
> In that case, I am waiting for you to present and get through patches
> that remove aCC, cl.exe, FCC, KCC, RCC, xlC_r, and xlC as well as clang
> from the code.
> 

That is irrelevant to the issue being address.  Just because something stupid
was done in the past doesn't mean that it should be stupidly be done in the
present.

Well, this might well be the issue to finally address all the non-viable 
proprietary  complier hood,  and perhaps to clean them all out finally.  
After all, this was/is a very agressive and ugly attack on GNU by Apple.

Maybe you should just turn to Apple and ask them for their tool kits.

Or better why don't you just use GCC.  What is your problem?  You have available
a perfectly fine, and superior Freedom Loving Free Software product available.
What would make you use a non-viable compiler like clang?

Reuvain


> ___
> Autoconf mailing list
> Autoconf@gnu.org
> https://lists.gnu.org/mailman/listinfo/autoconf


-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com 

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive 
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Add clang++ to AC_PROG_CXX

[Václav Haisman]

On 31.3.2016 18:46, Ruben Safir wrote:
> On 03/31/2016 12:31 PM, Jeffrey Walton wrote:
>> viable compiler
> 
> It will be viable when they release it under the GPL3.

In that case, I am waiting for you to present and get through patches
that remove aCC, cl.exe, FCC, KCC, RCC, xlC_r, and xlC as well as clang
from the code.

Good luck.


-- 
VH



signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Add clang++ to AC_PROG_CXX

[Ruben Safir]

On 03/17/2016 07:40 AM, Václav Haisman wrote:
>  makes sense to look for Clang as well as any other viable compiler.


that makes no sense.

-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Add clang++ to AC_PROG_CXX

[Ruben Safir]

On 03/31/2016 12:49 PM, Ruben Safir wrote:
> On 03/31/2016 12:31 PM, Jeffrey Walton wrote:
 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?
>>
>> +1. I kinda laughed when I read that, too.
>>
>> Apparently the project has a set of goals, and breaking the
>> configuration and compile in some instances meets the goals. Hence the
>> reason I laughed.
>>
>> Jeff
>>
>> ___
>> Autoconf mailing list
>> Autoconf@gnu.org
>> https://lists.gnu.org/mailman/listinfo/autoconf
>>
> http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html
> 
> 
> Re: clang vs free software
> 
> From: Richard Stallman 
> To: gcc at gcc dot gnu dot org
> Date: Fri, 24 Jan 2014 09:54:13 -0500
> Subject: Re: clang vs free software
> Authentication-results: sourceware.org; auth=none
> References: 

Re: Add clang++ to AC_PROG_CXX

[Ruben Safir]

On 03/31/2016 12:49 PM, Ruben Safir wrote:
> On 03/31/2016 12:31 PM, Jeffrey Walton wrote:
 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?
>>
>> +1. I kinda laughed when I read that, too.
>>
>> Apparently the project has a set of goals, and breaking the
>> configuration and compile in some instances meets the goals. Hence the
>> reason I laughed.
>>
>> Jeff
>>
>> ___
>> Autoconf mailing list
>> Autoconf@gnu.org
>> https://lists.gnu.org/mailman/listinfo/autoconf
>>
> http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html
> 
> 
> Re: clang vs free software
> 
> From: Richard Stallman 
> To: gcc at gcc dot gnu dot org
> Date: Fri, 24 Jan 2014 09:54:13 -0500
> Subject: Re: clang vs free software
> Authentication-results: sourceware.org; auth=none
> References: 

Re: Add clang++ to AC_PROG_CXX

[Ruben Safir]

On 03/31/2016 12:31 PM, Jeffrey Walton wrote:
>>> 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?
> 
> +1. I kinda laughed when I read that, too.
> 
> Apparently the project has a set of goals, and breaking the
> configuration and compile in some instances meets the goals. Hence the
> reason I laughed.
> 
> Jeff
> 
> ___
> Autoconf mailing list
> Autoconf@gnu.org
> https://lists.gnu.org/mailman/listinfo/autoconf
> 
http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html


Re: clang vs free software

From: Richard Stallman 
To: gcc at gcc dot gnu dot org
Date: Fri, 24 Jan 2014 09:54:13 -0500
Subject: Re: clang vs free software
Authentication-results: sourceware.org; auth=none
References: 

Re: Add clang++ to AC_PROG_CXX

[Ruben Safir]

On 03/31/2016 12:31 PM, Jeffrey Walton wrote:
> viable compiler

It will be viable when they release it under the GPL3.


-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Add clang++ to AC_PROG_CXX

[Ruben Safir]

On 03/31/2016 12:31 PM, Jeffrey Walton wrote:
>>> 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?
> 
> +1. I kinda laughed when I read that, too.
> 
> Apparently the project has a set of goals, and breaking the
> configuration and compile in some instances meets the goals. Hence the
> reason I laughed.
> 
> Jeff
> 
> ___
> Autoconf mailing list
> Autoconf@gnu.org
> https://lists.gnu.org/mailman/listinfo/autoconf
> 

Because the GNU project is not about making the best technology but
about creating and using Free Software.  And CLANG was designed
specifically to get around such goals and circumvent freedom asuring
measures that are guaranteed when one uses software under the GPL.

Its not rocket science we are talking about here.  If you want to fix
your "bug" apt-get GCC

Ruben



-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Add clang++ to AC_PROG_CXX

[Jeffrey Walton]

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

+1. I kinda laughed when I read that, too.

Apparently the project has a set of goals, and breaking the
configuration and compile in some instances meets the goals. Hence the
reason I laughed.

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Add clang++ to AC_PROG_CXX

[Václav Haisman]

On 31 March 2016 at 04:30, Ruben Safir  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  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

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf