If memory serves, all that stuff (which scares me, too, and was a real pain
to get working when I first developed the GNU-based build prior to the
open-source build) is due to the extremely extensive macro expansions done
in these files. Macros, even with backslashes in the macro definition,
become single lines in the expanded code so macros containing macros
containing macros, etc. become *really* long lines. So there are multiple
passes through the preprocessor in which macros that have end-of-line
markers are first expanded, then the markers translated to new lines, then
passed through the preprocessor again with different header files included
to expand macros that are invoked in the code inserted in the previous
level of macro expansion. The different header files are included by
translating INCLUDEx to #include in the x-1'th pass. I forget what the
stuff with the pragmas is.
Greg
Richard Gillilan
<[EMAIL PROTECTED]> To:
opendx2-dev@lists.berlios.de
Sent by: cc:
[EMAIL PROTECTED] Subject: [opendx-dev] Jaguar
compile
son.ibm.com
10/05/2002 07:37 PM
Please respond to
opendx-dev
I just got a new snapshot from CVS this morning and tried compiling
under MacOS 10.2 (Jaguar). Make has trouble in libdx. It tries to
compile
__buffer.c and similar files when it should probably be looking for
buffer.c. Buffer.c is evidently generated by macro-preprocessing of
__buffer.c
and then filtering and editing the output stream:
sed -e 's/[ ][ ]*\$/ $/' ./buffer.Z > __buffer.c
gcc -E __buffer.c | tr -s "\044" "\012" | sed -e '/^#/d' -e
's/INCLUDE2/#include/' -e 's/^pragma/
#pragma/' > buffer.c
This is pretty scary code to me. Anyone care to comment on why all the
post processing is
necessary?
Anyhow, could just be some changes need be made in makefile.am. Anyone
working on this section and understand what is going on?
Richard Gillilan
MacCHESS, Cornell
