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 Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
