out="out/make1.js"
main="make1/main.js"
gcc -C -E -H -P -nostdinc -undef -x c $main -o $out
node --harmony $out $@ cpp -P -H $main $out
Of course standalone preprocessor can be (ab)used to preprocess Javascript source files and any other files, as grandparent commenter suggested.
-C: compile but do not link (I think this is covered by -E)
-E: stop after running the preprocessor
-H: print the name of each header file included, indenting child #includes (what do you use this for? is it printed to stderr?)
-P: inhibit the generation of line markers from the preprocessor (I've used this before, but can't recall the problem it solves? Not expanding __LINE__?)
-nostdinc: do not search standard system directories for header files (/usr/include, /usr/local/include, ..., this is standard in the Linux kernel, since there is no libc)
-undef: do not predefine any system-specific or GCC macros (probably to not expand occurrences of sequences like "__GNUC__" and others from unexpectedly being expanded).
-x <language>: specify the language, rather then letting the compiler guess based on the file extension (is this required?)
It prevents #line directives which are useful for a C compiler but erroneous for javascript.
In the end I opted for a sed/awk/cat combo instead.
The only time I had to write m4 was admittedly in the context of autotools, but I found it really difficult to get answers to my questions about how everything worked.
http://blog.00null.net/post/144763147991/use-the-unix-m4-as-...
The C preprocessor is pretty simple (well, until you start wanting to evaluate C expressions as part of your #ifdefs) and very well-known. It's not inherently tied to C (QED), so it makes sense. There are other cases where people use it on something other than C, but as kevin_thibedeau mentions, he'd be better served with a more powerful (and generic) macro processor such as M4.