File extensions to use pre-processing C source?

Daniel Goldman <[email protected]> Wed, 23 Apr 2014 00:35:40 -0700
Newsgroups gmane.comp.gnu.m4.general
Message-ID <[email protected]>
I compile a lot of C source code. Adding m4 step will greatly simplify 
other steps (user manuals, help files, web pages) that share various 
macros in the source code, let me avoid using cpp on general text files. 
My question relates to file extensions to use for pre-processing the C 
source code. It seems there are three options:

*** Option #1: .c = backed-up source; .m4t = temporary file

        m4          gcc
bin2.c -> bin2.m4t --> bin2.o

....
        m4          gcc
win2.c -> win2.m4t --> win2.o

*** Option #2: .m4 = backed-up source, .c = temporary file

         m4        gcc
bin2.m4 -> bin2.c --> bin2.o

....
         m4        gcc
win2.m4 -> win2.c --> win2.o

*** Option #3: ???

Better way I have not thought of. :)

///// Pros of Option #2 seem:

A) more "logical" m4 works on .m4 files, gcc works on .c files.

B) can use builtin make rules for compiling .c files, do not need to 
write any new rules, like rule to go straight from .m4t to exefile.

//// Cons of Option #2 seem:

A) the source files ARE C files (many macros expanded, but no macro 
definitions), so seems weird to me using .m4 extension.

B) would likely look weird (odd) to someone else looking at C source 
code with .m4 extension.

C) adding backups for new .m4 extension and excluding backup for .c 
temporary files complicates backup situation a little.

///////

I have a file with many m4 macros called "macros.m4" (and macro.m4f 
frozen version) that is used in the m4 steps above.

I mostly know how to write makefiles, create library, compile, etc. so 
that's not the problem. Its a file extension question, wondering if 
anyone has an opinion which way makes more sense, or has already 
"solved" this minor but important question. I don't want to take the 
wrong path. :( Primarily because of Con B), I'm leaning toward Option #1 
".c -> .m4t -> .o". Any opinions appreciated.

Daniel