What is the best way to go from this: Makefile:
C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o \
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \ C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS) OBJS-common = \ ^Iinsn-attrtab.o \ ^Iinsn-automata.o \ ^Iinsn-emit.o \ ^Iinsn-extract.o \ to: call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp builtins.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp caller-save.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp calls.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp c-aux-info.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp c-common.c %1 %2 %3 %4 %5 %6 %7 %8 %9 and then finally to: //ALIAS EXEC ST2CMP,MEMBER=ALIAS //al...@po EXEC ST2CMP,member=al...@po //ATTRIBS EXEC ST2CMP,MEMBER=ATTRIBS //b...@reord EXEC ST2CMP,member...@reord //BITMAP EXEC ST2CMP,MEMBER=BITMAP //b...@load EXEC ST2CMP,member...@load //BUILTINS EXEC ST2CMP,MEMBER=BUILTINS //cal...@s EXEC ST2CMP,member=cal...@s //CALLS EXEC ST2CMP,MEMBER=CALLS //c...@aux@IN EXEC ST2CMP,membe...@aux@IN //c...@common EXEC ST2CMP,membe...@common I am happy to construct all of this on a Unix system with the various tools (m4 etc) available. But from the Unix system, I need to be able to generate the above very simple compile script, which is a precursor to creating very simple JCL steps (trust me, you don't want to see what ST2CMP looks like). Note that the JCL has the filenames truncated to 8 characters, listed twice, uppercased, and '-' and '_' converted to '@'. I assume I need a C program to do such a conversion. I'm happy to write that C program. But what's the best way to work with the existing infrastructure when writing and running that C program? One idea I had was to have a target that listed all the variables, and then just had an "echo" as the rule to make the ".o" from ".c", and then I could just go "make" to get all the object files listed out, and then I run a separate C program to convert that into the various scripts. Note that the objective is to basically get a list (in the above format) of all necessary C source in order to be able to compile (to assembler, not .o) C programs. I will be building a single executable, ie combining the C front end and i370 back end into a single executable. I know that it is possible, because I already have it working (on 3.4.6). Now the objective is to do it properly. :-) Also note that I'm not 100% sure what variables to use to get the minimum required source, although I would guess GCC_OBJS, C_OBJS plus the individual files listed in ALL_HOST_OBJS. This would be something that would be good to have an explicit variable for - the minimum C files required in the process of converting C to assembler (even though in normal configurations, those C files reside in different executables). So I would like to define such a variable prior to doing the above. Thanks. Paul. P.S. Here are the (intrusive) changes I have had to make so far to get (maybe 3/4 of) GCC 4.4 to compile on a C90-only platform: Index: gcc/system.h =================================================================== RCS file: /cvsroot/gcc4/gcc/system.h,v retrieving revision 1.1.1.1 diff -r1.1.1.1 system.h 180a181
#ifdef HAVE_SYS_TYPES_H
181a183
#endif
Index: include/sort.h =================================================================== RCS file: /cvsroot/gcc4/include/sort.h,v retrieving revision 1.1.1.1 diff -r1.1.1.1 sort.h 24a25
#ifdef HAVE_SYS_TYPES_H
25a27
#endif
Index: libcpp/include/cpplib.h =================================================================== RCS file: /cvsroot/gcc4/libcpp/include/cpplib.h,v retrieving revision 1.1.1.1 diff -r1.1.1.1 cpplib.h 26a27
#ifdef HAVE_SYS_TYPES_H
27a29,30
#endif
542,543c545,546 < ino_t ino; < dev_t dev; ---
/* ino_t ino; */ /* dev_t dev; */
Index: libiberty/xmemdup.c =================================================================== RCS file: /cvsroot/gcc4/libiberty/xmemdup.c,v retrieving revision 1.1.1.1 diff -r1.1.1.1 xmemdup.c 23a24
#ifdef HAVE_SYS_TYPES_H
24a26
#endif
Index: libiberty/xstrdup.c =================================================================== RCS file: /cvsroot/gcc4/libiberty/xstrdup.c,v retrieving revision 1.1.1.1 diff -r1.1.1.1 xstrdup.c 18a19
#ifdef HAVE_SYS_TYPES_H
19a21
#endif
ie very little. Not sure what the proper way to deal with that ino_t and dev_t is, but in the past I've simply created my own typedefs: typedef int ino_t; typedef int dev_t; and included them in config.h But I'll deal with that after I've got a comprehensive list of source files.
