gnb@bby.oz (Gregory N. Bond) (06/06/89)
I got just too frustrated with the Ingres esqlc preprocessor, which
fails in two main areas that make it bloody horrible to use in a
program development environment.
1) It doesn't return any sort of status if an error is found by the
pre-processor. This makes it unsuitable to use with the make of your
choice without hacks involving grep & test & tee & lots of ugly junk.
2) Any errors in the C code that are caught by the c compiler are
reported as errors in the C file. The line numbers etc don't
correspond very well to the input .sc file, making it dificult to find
the bug in the original program. What's even worse, things like
error(1) and GNUEmacs next-error function (C-X `) jump to the wrong
file. What's even worser (!) the info needed to tell the C compiler
about lines and files and guff is all included in comments in the
preprocessed C file, but not presented as "#line": directives.
This script lives in ~ingres/bin/esqlc, with the original binary in
~ingres/bin/esqlc.bin, and with some magic sed and grep fixes these
problems (to some extent). This has been tested on Ingres 5.0/04a on
a Sun running SunOS 3.5, but should work for any unix system. It may
not be needed for the 6.0 Ingres, with any luck they get it right
there.
The only problem is that esqlc.bin deletes blank lines (to no good
purpose as far as I can see), which means the line numbers reported by
the c compiler get progressivly further out of sync, and are re-synced
at each EXEC statement (which is where the esqlc program emits the #
line comments).
Side Comment: Don't RTI EVER USE this product?? Do they never use
any sort of software engineering tools? Its not that hard to get
right. Really. Ingres (at least 5.0) has SO many little annoyances,
this is only one of them. Lets hope 6.0 is a more polished product.
Shar file follows:
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,mnetor,pyramid,ubc-vision,ukc,mcvax,...}!munnari!melba.bby.oz!gnb
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of shell archive."
# Contents: esqlc
# Wrapped by gnb@baby on Tue Jun 6 13:13:35 1989
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'esqlc' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'esqlc'\"
else
echo shar: Extracting \"'esqlc'\" \(1071 characters\)
sed "s/^X//" >'esqlc' <<'END_OF_FILE'
X#! /bin/sh
X
X# This is a front end to the esql program that does 2 things:
X#
X# 1) It returns an error indication if the esql program fails.
X# This allows esql to be used sensibly in Makefiles.
X#
X# 2) It uncomments the lines like
X# /* # line 23 "filename.sc" */ /* random comments */
X# to make
X# # line 23 prog.sc
X# so the c compiler will refer to errors in the SOURCE file, not in the
X# processed C file. However, the blank line crunching of the esqlC
X# program will put these line numbers out by a little bit.
X# This means that error(1) or gnu-emacs next-error function (C-X `)
X# can find and deal with the errors
X
Xprog=/usr/ingres/bin/esqlc.bin # Renamed and moved
X
X# temporary files & names
Xerrlog=/tmp/esql.errs.$$
Xctmp=/tmp/esql.c.$$
X
Xtrap 'rm -f $errlog $ctmp' 0 1 2 3 15
X
Xfor i
Xdo
X $prog $i 2>&1 | tee $errlog
X grep -s '%' $errlog && exit 1 # Exit if errors
X
X base=`expr "$i" : '\(.*\)\.[^.]*'` # Strip trailing .xxx
X sed < $base.c > $ctmp \
X -e 's=^/\* # line \([0-9][0-9]*\) "\([^"]*\)" \*/.*$=# line \1 \2='
X mv $ctmp $base.c
XdoneEND_OF_FILE
if test 1071 -ne `wc -c <'esqlc'`; then
echo shar: \"'esqlc'\" unpacked with wrong size!
fi
# end of 'esqlc'
fi
echo shar: End of shell archive.
exit 0
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,mnetor,pyramid,ubc-vision,ukc,mcvax,...}!munnari!melba.bby.oz!gnbrobf@squid.rtech.com (Robert Fair) (06/08/89)
gnb@bby.oz (Gregory N. Bond) writes: >2) Any errors in the C code that are caught by the c compiler are >reported as errors in the C file. The line numbers etc don't >correspond very well to the input .sc file, making it dificult to find >the bug in the original program. What's even worse, things like >error(1) and GNUEmacs next-error function (C-X `) jump to the wrong >file. What's even worser (!) the info needed to tell the C compiler >about lines and files and guff is all included in comments in the >preprocessed C file, but not presented as "#line": directives. and presents a utility to make real #line comments. A much easier way of doing this is to make the ESQL/C compiler generate "#line" statements directly ! To do this, just use the -# or -p precompiler flags, i.e.: esqlc -# myprog.sc and then any C-compiler generated errors will be related directly back to the .sc file, as gnb wants. The -#/-p flags work in both INGRES 5.0 and 6.X, and are documented in "ESQL Companion Guide for C" in the section on command line options. Robert Fair RTI Tech Support