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

[Jeffrey Walton]

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

[Dustin Laurence]

Post by Jeffrey Walton
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