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