为了有条件地启用自动工具项目的一部分，我需要检查开箱即用的自动工具不支持的语言的短程序存根是否可以编译。
我需要类似 AC_TRY_COMPILE 的任意编译器可执行文件 - 创建一个临时文件，向其中写入一段代码，然后尝试调用编译器（之前通过 AC_CHECK_PROGS 找到）返回退出代码是否为零。
最优雅/最常见的方法是什么？
To conditionally enable a part of an autotooled project, I need to check whether a short program stub in a language not supported by autotools out of the box compiles or not.
I need something like AC_TRY_COMPILE with an arbitrary compiler executable – create a temporary file, write a piece of code to it, and try if invoking the compiler (found via AC_CHECK_PROGS before) returns an exit code equal to zero or not.
What is the most elegant/common way to do this?
发布评论
评论（2）
AC_TRY_COMPILE（已弃用并替换为AC_COMPILE_IFELSE) 仅支持有限的一组语言：C、C++、Fortran 77、Fortran、Erlang、Objective C、Objective C++ (来源）。configure.ac可以包含自定义 shell 代码 - 它只是被autoconf跳过（实际上是m4）。为什么不在 shell 中编写测试呢？如果您要使用多个测试，请将其包装在AC_DEFUN。AC_TRY_COMPILE(which is deprecated and replaced byAC_COMPILE_IFELSE) only supports a limited set of languages: C, C++, Fortran 77, Fortran, Erlang, Objective C, Objective C++ (source).configure.accan contain custom shell code - it just gets skipped over byautoconf(reallym4). Why not just write your test in shell? If you're going to use more than one test, wrap it in anAC_DEFUN.要启用自动工具项目的可选部分，您应该使用
--enable-something选项。不要让它依赖于构建环境中当前可用的内容。这很容易掩盖自动化构建中的错误。 （例如：众所周知，由于缺少构建依赖项或环境中的其他问题，Linux 发行版会发布有缺陷的软件包，在这种情况下，引发错误比静默处理更有帮助。）To enable an optional part of an autotooled project, you should use an
--enable-somethingoption. Don't make it dependent on what is currently available in the build environment. That is prone to mask errors in automated builds. (Example: Linux distributions have been known to ship crippled packages because of a missing build dependencies or other problem in the environment, where raising an error would have been more helpful than proceeding silently.)