Re: FREE C4gl Makefile - Holiday special

In article <3bdnkn$bn9@emory.mathcs.emory.edu>, johnl@informix.com (Jonathan Leffler) writes: <AOL LOST THE TEXT DANGIT!> Anyway, WOW! Johnathan, I must thank you profusely for the discussion on an INFORMIX 4GL makefile. I have to admit having to learn a thing or two here! But the most important thing is that I rated a response--remember any press is good press :) Seriously, there just isn't any of this kind of information you've presented here in the INFORMIX scriptures. I do hope your notes will be included in the next release of the documentation to save us all from having to hack. Some responses to your responses: JL writes: .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. TS writes: Scope was intended for 4GL. I'm a 4GL lover, and try to stay within the confines of the application development environment, albeit undefined when working from the command-line, except to say I won't be needing any Yacc or Lex stuff. That's why 4GL thrives! JL writes: 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.) TS writes: You got me on this one. RDS has not been a big fan of mine, and also unavailable at many sites--but this seems to be changing, and so are my skills. JL writes: 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. TS writes: Here's where I respectfully disagree, and hope INFORMIX et al will make the move to using MAKE. While I understand the intent of the 4GL is to make application development easier, I find great agony in the use of the i4gl and r4gl environments, partly due to irritating and non-customizable interfaces. I would never use the $#@$# "planned compile" even if my life depended on it. Don't get me wrong, I LOVE the 4GL, but there's a better way when it comes to the assembly process of the application. The INFORMIX scriptures are silent to a large degree when it comes to professional compilation. Most of the projects I have been on would not tolerate the time-wasting features of i4gl/r4gl. As a result, I've put together a makefile I know will work in most cases, and take care of the process. Since I don't do much ESQLC, I don't worry about it much. I DO like ESQLC, don't get me wrong, just haven't had the joy to work with it. To be realistic, I create MANY makefiles, and usually give them a suffix of mk, as in program.mk. Many programmers use program.mak. Whatever. The point is, would it not be most beneficial to include a template Makefile with each release of INFORMIX? Then, we simply name them different names with the libraries predefined in the makefiles. C4gl does not clean up after itself, leaving .c and .ec files behind. Nor is it easy to modify, especially for the novice. I would rather spend my time explaining to a programmer how a make file works than trying to explain c4gl. INFORMIX doesn't need to protect all programmers--maybe they could include BOTH the c4gl and a makefile with each new release? We would all learn a thing or two wouldn't we? JL writes: > cat $(FILES) | sed 's/^GLOBALS/#GLOBALS/' > $(SFGL) I fundamentally disagree with this approach to compiling RDS code. It works, don't get me wrong, but I don't like it. There should be rules to create .4go files from the individual .4gl files, and then a rule to collect all the .4go files into the .4gi. What this rule does is create a single .4gl file by merging all the source code into a single file and then makes fglpc compile the whole lot at once. Not a good idea. This also explains why there are no rules handling .4go and .4gi files. And the comment about having to indent GLOBALS rules is ghastly. TS writes: Here again my orientation has NOT been RDS. So I came up with a cheap way to 4go ( 'scuse the pun ) the assemblage of many .4go files into the 4gi. I did not spend a lot of time on this one, as I develop separate src modules that would normally compile to object files ( .o ), and then linked at cc time. The RDS stuff is subordinate to the cc stuff in this instance. If you change a module, the catting together creates a new single-source file, so you would have to be careful not to consider the single source file for changes. It would be recompiled, but if any of the separate source modules changed, keep in mind the single-source will be overwritten. A RDS orientation is in my future with INFORMIX, as I hear the c4gl is going the way of the dodo bird. If this is true I will be sick over the loss of the cc version of 4gl. It means the end of INFORMIX 4GL as I learned it. But everything changes, I hope this is a smart move. JL writes: Note that many versions of MAKE support suffix-rewriting macros of the form: FILES.4gl = file01.4gl file02.4gl file03.4gl FILES.o = ${FILES.4gl:.4gl=.o} FILES.4go = ${FILES.4gl:.4gl=.4go} TS writes: I like it. Best discussion on MAKE for INFORMIX 4GL I've ever seen. Keep up the good work and stuff your makefile in the next release of INFORMIX documentation. ( Your makefile is now a part of my tools. It ranks right up there with ex30.4gl as essential software. ) Happy Holidays! Tim Schaefer The Computer Business Company, Inc.