c - 使用带文件扩展名 .r 的 autotools 作为 header ，不是 ratfor，而是 C 编程

Question

我正在使用这本书 http://www.cs.rit.edu/~ats/books/ooc.pdf “ANSI-C 中的面向对象编程”，作者 Axel T Schreiner。他使用的 makefile 和编译一样工作正常。因此，C 编译器和 make 实用程序可以毫无问题地将 .r 文件用作包含文件。 (.r 代表表示，以练习信息隐藏。)

现在我已经发展到要手动编码的地步了。我通常毫无问题地使用自动工具。对于 .r 文件，我遇到了问题。命令 autreconf -iv 返回以下错误:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: ...............................
..... (snip)
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
Makefile.am: error: Ratfor source seen but 'F77' is undefined
Makefile.am:   The usual way to define 'F77' is to add 'AC_PROG_F77'
Makefile.am:   to 'configure.ac' and run 'autoconf' again.
autoreconf: automake failed with exit status: 1

我希望 autoheader/autoreconf 不将 .r 文件标记为 ratfor 源文件，而是将它们用作 C 包含文件，只是另一个头文件。

我搜索了谷歌，但主要是找到了 autoheader 的手册，据我所知，它没有帮助。

有没有办法让 autotools 将 .r 文件(或与此相关的任何其他后缀)视为 C 代码而不是 ratfor 源代码？

Answer 1

的确，头文件的.h后缀只是约定，不是规定。事实上，将头文件作为源文件的一个特殊类别的整个想法基本上是约定俗成的，即使这是标准本身遵守的约定。尽管如此，这些都是非常强大的惯例。

Automake 通过依赖文件命名和组织来遵守此类约定来实现其许多自动化行为。特别是，它通过文件名后缀识别源文件类型。据我所知，其这样做的规则是不可配置的。使用标准文件命名约定是使用 Autotools 的代价之一。

但是可以稍微改变一下这个规则。请特别注意，在 *_SOURCES 变量中列出头文件的唯一目的是确保它们被打包到(源)发行版中。 Automake 不依赖于任何其他目的，特别是，它不依赖于依赖性跟踪。但是还有另一种方法可以告诉 Automake 应该进入分发的文件:将它们列在 EXTRA_DIST 变量的值中。因此，从您的 *_SOURCES 变量中删除您的 .r 文件并将它们放在 EXTRA_DIST 中将解决问题。

示例:

测试.c

#include "test.r"

int x = 1;

int main(void) {
    return x;
}

测试.r

#ifndef TEST_R
#define TEST_R

extern int x;

#endif

Makefile.am

bin_PROGRAMS = test

test_SOURCES = test.c
EXTRA_DIST = test.r

(省略 configure.ac——不说明)