On 31 March 2016 at 04:30, Ruben Safir <ruben@xxxxxxxxxxxx> 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 <eggert@xxxxxxxxxxx> 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@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
