Re: FREE C4gl Makefile - Holiday special

>From: inxutil@aol.com (Inxutil) >Subject: FREE C4gl Makefile - Holiday special >Date: 24 Nov 1994 08:30:05 -0500 >X-Informix-List-Id: <news.9970> >I had numerous requests for a makefile with rules to get from 4GL >to exe, so I'll post it here to make it a bit easier to obtain. >[ ... ] but the price is right, eh? And although the general concept is great and most of the details are fine, there are some troubles which could lead to serious problems for those upgrading to releases like 4.12, 4.13, 6.00 or 6.01. The main problem is discussed after a line starting with equals signs. >This is not the perfect and only way to do it, and there's probably >better makefiles around. Any improvements would be gladly accepted! Correct -- and the same applies to my suggestions! >.SUFFIXES: .per .per~ .frm .a .o .c .c~ .ec .4gl~ .4gl This rule means that the intermediate files (.ec, .c -- and .4ec for those using 6.00, 6.01 or 4.13) have higher priority than the .4gl files, so that if they exist, they will be used, even if the .4gl file has changed. This is not good, I suggest. To get around this, you have to do more violence to the SUFFIXES list: .SUFFIXES: # Clean out the current suffixes list .SUFFIXES: .4gl~ .4gl .ec~ .ec .c~ .c .o .a .per~ .per .frm This is OK as far as it goes, but it effectively deletes any Yacc, Lex, Fortran, Pascal, etc rules that are built into MAKE. This is usually not a major issue. Also, I see no null-suffix rules for converting a single .4gl or .ec file directly into an executable. Nor is there any mention of .4gi or .4go or .4ge files in the suffix list. That makes life more difficult than necessary. (Note that ESQL/C files can exist in their own right; that's why I added .ec~ to the suffix list.) >.per~.per: > ${GET} ${GFLAGS} $< > >.c~.c: > ${GET} ${GFLAGS} $< Err... what about the .4gl~.4gl and .ec~,ec rules? >.c.o: > @echo "--------------------------------- .c.o" > $(CC) -c $(CFLAGS) $*.c 2>&1 At a trivial level, having the echo lines around would irritate me, so I'd get rid of them. That is not a functional criticism -- purely a cosmetic one. =========================================================================== The rules exemplified by the .ec.c and .4gl.o rules, shown below, are my primary concern, and the reason I'm spending time on this email. That, plus the related library rules, also shown below... >.ec.c: > $(FGLC2) -4GL $*.ec >.4gl.o: > $(FGLC) $*.4gl > $(FGLC2) -4GL $*.ec > $(CC) -c $(CFLAGS) $*.c 2>&1 > $(RM) $*.c $*.ec You should use the C4GL script to control all compilations, including the link phase. You should not try to second guess the C4GL script -- not least because it changes between releases. For example, in the 4.13 and 6.00 and 6.01 releases, the libraries are located in the ${INFORMIXDIR}/lib/tools subdirectory, not in ${INFORMIXDIR}/lib. The lists of libraries changes; 6.0x has a radically different list. This makefile could not take advantage of shared libraries. For these and other reasons, you should not be using the fglc and fglc2 programs directly -- you should be using the c4gl script instead. As a secondary issue, I'd prefer to see the ESQL/C file compiler nominated by a separate macro (I use ESQLC), even though in the 4.1x versions, the ESQL/C compilation must be done by c4gl -- trying to use a 5.0x ESQL/C compiler with 4.1x I4GL is not a workable option. Even if it does link (debatable), there is no guarantee that it will work correctly. ># LIBS out of c4gl ># VI the c4gl script to confirm the libraries! ># ># 4.1 version >LIBS=${INFDIR}/lib/lib4gl.a ${INFDIR}/lib/libnforms.a >${INFDIR}/lib/libfesql.a >-lcurses ># 2.1 version ># LIBS=${INFDIR}/lib/lib4gl.a ${INFDIR}/lib/libforms.a >${INFDIR}/lib/libsql.a >-lcurses The lists of libraries are unnecessary, because C4GL should be used to do the link. > FGLC=${INFDIR}/lib/fglc > FGLC2=${INFDIR}/lib/fglc2 In 4.13, 6.00 and 6.01, fglc and fglc2 (and fglc3) are all one-line shell scripts (padded out to around 30 lines with a copyright notice) which then run c4gl with appropriate arguments to achieve the required effect. This much backwards compatability we have retained for you. Thus, this makefile will compile to object code OK with the latest versions of the product, but it will not link correctly. > ESQL=${INFDIR}/bin/esql > LIBDIR=${INFDIR}/lib > FORMFGL=${INFDIR}/bin/form4gl LIBDIR needs to change in 4.13, 6.00 and 6.01, as noted above. The rules this far down the file should be put into a file and placed in a well-known directory -- I usually use a file called informix.mk, and I usually keep it in somewhere like ${PROJECTDIR}/etc; an alternative that could be considered is ${INFORMIXDIR}/etc, but be careful especially when the Informix software is upgraded. I would then use the MAKE include directive to copy the rules into the local makefile: include ${PROJECTDIR}/etc/informix.mk If your version of make doesn't support this (including the environment variable in the include file name), then get a version which does -- GNU Make, for instance. ># RDS OBJECTS >########################################################################## ># >SFGI = S_${BASE_FGL_FILE}.4gi >SFGO = S_${BASE_FGL_FILE}.4go > ># Single catted together file of all your source: >SFGL = S_${BASE_FGL_FILE}.4gl > ># RDS runtime: >NFGO = R_${BASE_FGL_FILE} > ># RDS DEBUG runtime: >NFDB = D_${BASE_FGL_FILE} > ># Runner shell script created for you: >RUN_SH = R_${BASE_FGL_FILE}.sh > ># Debug shell script created for you: >DBG_SH = D_${BASE_FGL_FILE}.sh > ># Basic C compile version: ># all: $(EXE) $(FRMS) $(SFGL) > ># Compile RDS and C version: >all: $(EXE) $(FRMS) $(SFGL) $(SFGO) $(SFGI) $(NFGO) $(NFDB) > >$(EXE): $(GLOBALS) $(FOBJS) $(COBJS) > $(CC) $(CFLAGS) $(GLOBALS) $(FOBJS) $(COBJS) $(LIBS) -o $(EXE) > ls -l $(EXE) > strip $(EXE) > ls -l $(EXE) This link rule has already been discussed above -- don't do it this way, or, if you must, define CC=c4gl. On second thoughts, don't do it this way, period! >$(NFGO): $(SFGOBJS) > cfglgo $(SFGOBJS) -o $(NFGO) -s > @echo "$(NFGO) $(SFGO)" > $(RUN_SH) > chmod 755 $(RUN_SH) This is a mixed rule -- it does two things, and one of them is unnecssary. You should not try to do two operations in a single make rule; it leads to confusion. This rule creates a shell script, and it creates a non-customised custom runner. Creating a non-customised custom runner is pointless -- the standard runner can be used instead. This chews up disk space even faster than usual. Creating the shell script, on the other hand, is a very good idea. I normally handle it slightly differently, but what the heck. (I have a ${PROJECTDIR}/bin directory which contains a script run_prog which is linked to prog01, prog02, etc. When the prog02 script is run, it arranges to run the relevant runner (custom or standard)