On 3/16/2016 4:02 AM, Václav Haisman wrote: > On 15 March 2016 at 17:35, Paul Eggert <egg...@cs.ucla.edu> 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. >
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. -- Earnie _______________________________________________ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
