Re: 4gl Libraries

On Mon, 20 Apr 1998 17:15:36 GMT, joshua@oklahoma.net wrote: >I am in a one man shop, RISC 6000, >Informix 4gl Rel 4.11. > >I am having problem finding out how to maintain a library of 4gl or C >subroutines. It appears that my predacessor could not find out >either. >There are several "common" routines that have been copied into >numerous >programs rather than being placed into a library somewhere. I have >the >following 4gl scripts or modules C4GL R4GL script and I4GL. I am able >to create object linkable files, but unable to get them to compile >into >MAIN progs. My manuals are Ref Man 4.0. > >If you can give me a hint I would appreciate it > >Thanks, > >Joshua White 1. Forget about i4gl. It doesn't work. 2. Put all source code (the .4gl module files) containing common routines in one directory somewhere (see below). 3. Put all special source code for one program into one directory. 4. Use separate directories for each program. 5. Use a standard make file in each program directory. There are many *complex* make file systems out there. They all go far beyond my needs. I like it simple. Here is my standard make file for c4gl compilation (I don't know anything about r4gl. I don't debug programs so I don't use it. I write correct programs instead. Reasonably easy in 4GL.): SHELL=/bin/sh .SUFFIXES: .SUFFIXES: .o .4gl .c .frm .per .iem .msg .4gl.o: c4gl -globcurs -z -c $< rm -f $*.c $*.ec .4gl: c4gl -globcurs -z $< -o $* rm -f $*.c $*.ec $*.o .per.frm: form4gl $* .msg.iem: mkmessage $*.msg $*.iem BINARIES= mainprog forma.frm formb.frm mainprog.iem all: $(BINARIES) MAINOBJ=glmain.o $(SRCDIR)/srccom/mod1.o $(SRCDIR)/srccom/mod2.o $(SRCDIR)/srcc/cprog1.o \\ par3.o part2.o part1.o mainprog.o mainprog: $(MAINOBJ) c4gl -globcurs -z $(MAINOBJ) -o $@ recomp: rm -f $(BINARIES) rm -f *.o *.frm make inst: (cd $(DBPATH); rm -f $(BINARIES)) cp $(BINARIES) $(DBPATH) If you copy the above from this mail you will have to replace the spaces at the start of many lines with a single tab character. For your old version you have to remove the -globcurs and probably the -z from the c4gl commands. Create the SRCDIR environement variable pointing to your main source directory. Put your common 4GL source modules in the srccom directory in your main source directory. Put your C-programs in the srcc directory. For each main file replace mainprog, forma, formb and so on with whatever you have named your program files. Add files as needed to the MAINOBJ spesification. Remove the mainprog.iem if you have no message file (help file). Now you can simply type make, or better m if you have the obvious alias defined, to compile and link your code. inst (make inst) is to install your binary code in one directory. recomp (make recomp) is to recompile everything in case you upgrade and that is needed. In newer versions you no longer need the rm commands, but they also do no harm. In your version you probably want it there to remove all the .c and .ec files that are created. You need a small variation to the above make file for compiling C-programs and the common 4GL modules (in $SRCDIR/srccom). Mine for the 4GL modules looks like this: SHELL=/bin/sh .SUFFIXES: .SUFFIXES: .o .4gl .c .frm .per .c.o: c4gl -globcurs -c $< .4gl.o: c4gl -globcurs -c $< rm -f $*.c $*.ec .4gl: c4gl -globcurs $< -o $* rm -f $*.c $*.ec $*.o .per.frm: form4gl $* BINARIES= glcom.o mod1.o mod2.o all: $(BINARIES) Here you simply add more names to the BINARIES spesification as you create more common modules. The make file for your C-programs is left as an excercise. I have heard some use archives instead. I have never bothered doing that. I can't realy see any benefits. With the above setup you have to make sure the common modules are compiled before you attempt to make any program. If not you will get an error message. It's probably easy to get rid of it, but I don't want to as I don't want to be able to compile common modules (new or changed) while I am in the directory used for one of the programs. I either mainain common modules or a program, not both at one time. For a one man show you may or may not want source code control of some sort. I never used it when I was alone, but it might be a good idea. If you do be carefull about SCCS due to potential year 2000 problems. Otherwise source code control is easy to add to the above setup. Nils Myklebust NM Data AS Norway E-mail: Nils.Myklebust@nmdata.com FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html (Now with ODBC info under "Third party products".)