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
