Используйте autotools с расширением файла .r для заголовка, а не ratfor, а C-программирование

Я работаю с книгой http://www.cs.rit.edu/~ats/books/ooc.pdf «Объектно-ориентированное программирование в ANSI-C», Аксель Т. Шрайнер. Make-файлы, которые он использует, работают нормально, как и компиляции. Поэтому у компилятора 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, просто еще один заголовочный файл.

Я искал в Google, но нашел в основном руководство для автозаголовка, которое, насколько я вижу, не помогает.

Есть ли способ заставить автоинструменты рассматривать файлы .r (или любой другой суффикс в этом отношении) как код C, а не исходники ratfor?


person guus    schedule 21.05.2018    source источник
comment
Вместо того, чтобы использовать расширения, которые уже означают что-то другое, почему бы не использовать что-то вроде .r.h в качестве нового типа расширения?   -  person Chris Dodd    schedule 22.05.2018
comment
@ChrisDodd Это действительно очень хороший совет. И я разрываюсь между использованием этого и ответом на мой вопрос от Джона Боллинджера.   -  person guus    schedule 22.05.2018


Ответы (1)


Это правда, что суффикс .h для заголовочных файлов является лишь соглашением, а не правилом. На самом деле вся идея заголовочных файлов как отдельной категории исходных файлов в основе своей традиционна, даже если это соглашение соблюдается самим стандартом. Тем не менее, это очень строгие соглашения.

Automake реализует многие возможности автоматизации, полагаясь на именование и организацию файлов, чтобы соответствовать таким соглашениям. В частности, он распознает типы исходных файлов по суффиксам имен файлов. Насколько мне известно, его правила для этого не настраиваются. Использование стандартных соглашений об именах файлов является одной из затрат при использовании Autotools.

Но можно немного изменить это правило. В частности, обратите внимание, что единственной целью перечисления файлов заголовков в переменной *_SOURCES является обеспечение их упаковки в (исходные) дистрибутивы. Automake не использует его для каких-либо других целей, и, в частности, он не использует его для отслеживания зависимостей. Но есть альтернативный способ сообщить Automake о файлах, которые должны попасть в дистрибутив: перечислить их в значении переменной EXTRA_DIST. Таким образом, удаление файлов .r из переменных *_SOURCES и помещение их вместо них в EXTRA_DIST решит проблему.

Пример:

test.c

#include "test.r"

int x = 1;

int main(void) {
    return x;
}

test.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 опущен — не иллюстрирует)

person John Bollinger    schedule 21.05.2018
comment
Большое спасибо за ваш ответ, который точно отвечает на мой вопрос. Я протестировал его, и он прекрасно работает. В практическом смысле я разрываюсь между использованием этого решения и советом Криса Додда в комментарии: *.r.h. На данный момент я буду придерживаться *.r, так как он соответствует настройке Акселя Шрайнера. - person guus; 22.05.2018