[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Goldman
Subject: Re: File extensions to use pre-processing C source?
Date: Thu, 24 Apr 2014 00:48:58 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

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:

catvar.h -> catvar.m4.h

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,

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 
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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]