I am working with the book http://www.cs.rit.edu/~ats/books/ooc.pdf "Object-Oriented Programming in ANSI-C" by Axel T Schreiner. The makefiles he uses work fine as do the compiles. So the C compiler and the make utility have no problem with using .r files as include files. (The .r stands for representation in order to practice information hiding.)
Now I have progressed to a point where I want to code it by hand. I normally use the autotools without a problem. With .r files I run into a problem. The command autreconf -iv returns the following errors:
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
I would like autoheader/autoreconf to not brand the .r files as ratfor source files, but just use them as a C include file, just another header file.
I searched google, but found mainly the manual for autoheader which as far as I can see doesn't help.
Is there a way to make autotools consider .r files (or any other suffix for that matter) to be C code in stead of ratfor sources?
It is true that the .h suffix for header files is only a convention, not a rule. In fact, the whole idea of header files as a distinguished category of source files is fundamentally conventional, even if it's a convention that the standard itself observes. Nevertheless, these are very strong conventions.
Automake achieves many of its automation behaviors by relying on file naming and organization to comply with such conventions. In particular, it recognizes source file types by the filename suffixes. To the best of my knowledge, its rules for doing so are not configurable. Using standard file-naming conventions is one of the costs of using the Autotools.
But it's possible to bend that rule a bit. Note in particular that the only purpose served by listing header files in a *_SOURCES variable is to ensure that they get packaged into (source) distributions. Automake does not rely on that for any other purpose, and in particular, it does not rely on that for dependency tracking. But there is an alternative way to tell Automake about files that should go into the distribution: list them in the value of the EXTRA_DIST variable. Thus, removing your .r files from your *_SOURCES variable(s) and putting them instead in EXTRA_DIST will solve the problem.
Example:
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 omitted -- not illustrative)