Re: Source code control & revision numbers

Jacob Salomon wrote: > > Hi Folks, > > At my place, we want to enhance the way we do source code control. This > is with an eye toward including the module name and revision number in > all error messages. We are using Fourgen as our development environment > and are calling a library function which eventually calls errlog(). We > are currently using RCS for source code control. > > In every [blessed] 4GL source module in our application, we have > commented lines that look like: > > # $RCSfile: main.4gl,v $ > # $Date: 1996/08/01 18:21:47 $ > # $Revision: 1.1 $ > > Is there any way in 4GL that we might use these string values in > variables? We'd like to be able to pass this to the error-handling > routines. Would another source-code control program make this possible? As far as I'm aware there's no particular reason that they should be in comments. You could convert the comments to string literals. e.g. CHAR filename(60) LET filename = "$RCSfile: main.4gl,v $" RCS just looks for the strings and ignores the context. I've seen them in {} style comments. Putting them into strings has the added advantage that all that info goes into the binary so that you can inspect the binary to determine which version it is. Does anyone know any trick to manage that with .per/.frm files? > Also, in C language, we have built-in macros like __FILE__ and __LINE__ > and I'm wondering if we can use these in any way in 4GL? I already have > tried explicitly using them in a 4GL file and the 4GL preprocessor > downshifted the symbols, so that they would never have made it to the C > compiler intact. Even not thinking about the C compiler, it was an > error; it complains that the variable __file__ has not been defined. > > So is this possible any less direct way? (Please don't mention C; this > must work within the the 4GL source module.) What you need is a pre-processor to process the file before it's presented to the C compiler. I recently visited a site where they'd gone to town on using macros (with #include to bring in the macro definitions). Due to problems too complex to go into now we had to edit some portions of the original version but in order to work out what to edit we had to read the expanded version, using dumb terminals so we had to put 2 terminals side by side to compare them... I digress. What they did was to use cpp. They used a different filename suffix for the original and then used make or scripts, I can't remember which, to pre-process these to .4gl. I believe C compilers are tending to do away with the separate cpp so you may not even have it to hand. If not, take a look at m4 (should be part of your Unix, if not I think there's a Gnu version). That might do the job. Ian