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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jeffrey Walton-3
On Thu, Mar 31, 2016 at 1:22 PM, Ruben Safir <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

<unlurk>

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?

</unlurk>

Dustin


_______________________________________________
Autoconf mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf
Loading...