Re: File extensions to use pre-processing C source?

[Daniel Goldman]

Hi Raphael,

Thanks. I learned a lot from what you said. Here's what I conclude:

////// Answered my basic question (one vote, anyway)

- You keep the source files as .c files, so that is one vote confirming 
what I was leaning toward.

Q*** Anybody else have a different opinion whether to use .c or .m4 
extension for source files? Or is .c obvious choice?

////// I need to figure out about line numbers

Sounds like keeping line numbers consistent is tricky. Obviously, I want 
line number in gcc error message to be same as line number in .c (and 
.h) source file (not same as line # in .i or .i.c file created by cpp or 
m4). I noticed -s command line option to synchronize lines, I guess I 
will have to play around with that.

Q*** Can anyone say which works better for line # consistency:

m4 -> cpp -> gcc
cpp -> m4 -> gcc

////// Maybe don't use make

- Maybe I can simplify by moving away from make, just use bash to issue 
commands. Most of the time, I compile all the source anyway. And I 
already use bash to build the user guides. The data analysis software 
gets compiled to many different versions, each with different data being 
analyzing, state analyzing the data, desktop vs web front end, etc., so 
everything normally needs recompiling anyway. I recently moved to an 8 
thread e3 cpu, learned xjobs, so things are snappy.

Q*** Any thoughts on forgetting about make?

////// Need to think about macros in data structure headers

My .h files seem to have some five kinds of information:

"macros.h" - cpp macros (60,000 lines)
"common.h" - struct definitions; #include macros.h (2,000 lines)
"catvar.h", "chtvar.h", etc. - array definitions (130,000 lines)
"protypes.h" - auto-generated function prototypes (15,000 lines)
"externs.h" - auto-generated extern global definitions (1,000 lines)

The .c source is about 200,000 lines, including utilities to import 
data, generate web front ends, do AJAX, etc, etc.

The "catvar.h" (categorical var), etc. data structures need to be in the 
headers, cannot be put into a .c files, because there are different 
groups of C files that need the same data structures.

My guess is most of "macros.h" and "common.h" will get converted to m4 
macros, in single "macros.m4" file. That way I can use them for 
operations on general text, and it works better. "catvar.h", etc with C 
data structures will stay the same.

But your point is "catvar.h", "protypes.h", etc. also have macros (they 
do). So I could run cpp first before running m4, as you suggest. Or 
maybe I could also pre-process the .h header files with m4, as follows:

         m4
catvar.h -> catvar.m4.h

....
         m4
ticvar.h -> ticvar.m4.h

Then do the compiles (using the .m4.h headers):

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

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

Q*** If you can follow that, any comments? Again, any idea if the gcc 
error line numbers would match up with the original .h files?

/////////////

Q*** "Also m4 macro uses may be generated as a result of expanding C 
macros."? I don't understand how that would happen, I'd be interested to 
see an example.

Thanks again,
Daniel

On 4/23/2014 12:48 AM, Raphael 'kena' Poss wrote:
> Dear Daniel,
>
> here at UvA we have developed a C extension which requires m4 preprocessing, so 
> I wanted to share the experience. Maybe you will find something for you there.
>
> In our setting we use m4 *after* the C preprocessor.
> So the chain is:
>
>     .c -> (cpp) -> .i -> (m4) -> .i.c -> (gcc) -> .o
>
> The reason is that we want to expand m4 macros in all headers imported from 
> #include.
> Also m4 macro uses may be generated as a result of expanding C macros.
> To manage the compile chain of course you can write Makefiles, but for our 
> application I found it easier to write a custom compiler driver that invokes 
> the right tools depending on the type of files given on the command line.
>
> Also any way you choose, you may want to care about line numbers. The format used by m4 
> is slightly different from the one expected/used by gcc. Especially if you run cpp first, 
> you want m4 to "know" about custom line number information. I made a patch to 
> m4 in that direction, posted on the m4-patches mailing list in 2009/2010, but it has not 
> been merged yet. Ping me if you are interested.
>
> Best regards,