 |
|
| Computers Forum Index » Computer - Databases - Ingres » ESQLC problem... |
|
Page 1 of 1 |
|
| Author |
Message |
| Mark... |
Posted: Fri Oct 16, 2009 11:51 am |
|
|
|
Guest
|
Hi,
I have a large amount of legacy C code that contains embedded SQL
statements. One header file contains lots of type definitions and is
included in many places via EXEC SQL INCLUDE 'file.h' statements.
There is now a requirement to make some of the string sizes dependent
on a compiler define, for example:
#ifdef BIG_STRING
#define STRING_LEN 256
#else
#define STRING_LEN 80
#endif
typedef struct {
...
char data[STRING_LEN];
...
The ESQLC preprocessor cannot cope with the #ifdef's. Does anyone
have a simple workaround for this kind of problem? i.e. One that
does not involve splitting the header file up which would result in
changes to 100's of source files.
--
(\__/) M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking most articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.
[Reply-to address valid until it is spammed.] |
|
|
| Back to top |
|
|
|
| Karl Schendel... |
Posted: Fri Oct 16, 2009 4:10 pm |
|
|
|
Guest
|
On Oct 16, 2009, at 3:51 AM, Mark wrote:
Quote: Hi,
I have a large amount of legacy C code that contains embedded SQL
statements. One header file contains lots of type definitions and is
included in many places via EXEC SQL INCLUDE 'file.h' statements.
There is now a requirement to make some of the string sizes dependent
on a compiler define, for example:
#ifdef BIG_STRING
#define STRING_LEN 256
#else
#define STRING_LEN 80
#endif
typedef struct {
...
char data[STRING_LEN];
...
The ESQLC preprocessor cannot cope with the #ifdef's.
What version are you running? This sort of thing works for me,
although a
wee bit of command line trickery may be needed.
x.h:
#ifdef BIG_STRING
#define LEN 100
#else
#define LEN 200
#endif
exec sql begin declare section;
char buf[LEN];
exec sql end declare section;
-----
x.sc:
exec sql include 'x.h';
main(){}
----
esqlc -o.ch x.sc
creates an x.c that includes x.ch
cc -DBIG_STRING -o x x.c
works for me.
The -o.xx says write preprocessed exec-sql-include files with
the extension xx. (The -o flag by itself says don't output the
preprocessed include file, in the case where it's done elsewhere.)
If this isn't what you are after, please give us more details about
how the includes are set up, how you are running the pre-
processor, what version, and where BIG_STRING is defined.
Karl |
|
|
| Back to top |
|
|
|
| Mark... |
Posted: Tue Oct 20, 2009 2:17 pm |
|
|
|
Guest
|
On Fri, 16 Oct 2009 08:10:35 -0400, Karl Schendel
<schendel at (no spam) kbcomputer.com> wrote:
Didn't see your post until now 'cos the subject had changed.
Quote: On Oct 16, 2009, at 3:51 AM, Mark wrote:
Hi,
I have a large amount of legacy C code that contains embedded SQL
statements. One header file contains lots of type definitions and is
included in many places via EXEC SQL INCLUDE 'file.h' statements.
There is now a requirement to make some of the string sizes dependent
on a compiler define, for example:
#ifdef BIG_STRING
#define STRING_LEN 256
#else
#define STRING_LEN 80
#endif
typedef struct {
...
char data[STRING_LEN];
...
The ESQLC preprocessor cannot cope with the #ifdef's.
What version are you running? This sort of thing works for me,
although a
wee bit of command line trickery may be needed.
Ingres 2 v 2.6/0305
Quote: x.h:
#ifdef BIG_STRING
#define LEN 100
#else
#define LEN 200
#endif
exec sql begin declare section;
char buf[LEN];
exec sql end declare section;
-----
x.sc:
exec sql include 'x.h';
main(){}
----
esqlc -o.ch x.sc
creates an x.c that includes x.ch
cc -DBIG_STRING -o x x.c
works for me.
The -o.xx says write preprocessed exec-sql-include files with
the extension xx. (The -o flag by itself says don't output the
preprocessed include file, in the case where it's done elsewhere.)
If this isn't what you are after, please give us more details about
how the includes are set up, how you are running the pre-
processor, what version, and where BIG_STRING is defined.
Our situation is a little different. The header file in question has
to be included in non-esqlc (plain C) code so we do the following
(based on your example):
x.h:
#ifdef BIG_STRING
#define LEN 100
#else
#define LEN 200
#endif
char buf[LEN];
-----
x.sc:
exec sql begin declare section;
exec sql include 'x.h';
exec sql end declare section;
main(){}
----
E_EQ0244 Syntax error in 'ifdef'.
--
(\__/) M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking most articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.
[Reply-to address valid until it is spammed.] |
|
|
| Back to top |
|
|
|
| Michael Touloumtzis... |
Posted: Tue Oct 20, 2009 5:08 pm |
|
|
|
Guest
|
With the downside that it might complicate the build pipeline there is
always the possibility of passing some of your files through the C
preprocessor step (only) before the esqlc step. So it would be:
preprocess (a file subset) -> esqlc -> ( preprocess -> compile ->
link )
MikeT
On Oct 20, 10:51 am, Karl Schendel <schen... at (no spam) kbcomputer.com> wrote:
Quote: On Oct 20, 2009, at 6:17 AM, Mark wrote:
Our situation is a little different. The header file in question has
to be included in non-esqlc (plain C) code so we do the following
(based on your example):
x.h:
#ifdef BIG_STRING
#define LEN 100
#else
#define LEN 200
#endif
char buf[LEN];
-----
x.sc:
exec sql begin declare section;
exec sql include 'x.h';
exec sql end declare section;
main(){}
----
esqlc -o.h -o x.sc
E_EQ0244 Syntax error in 'ifdef'.
I see, it's because the header is inside an exec sql declare
section surrounding the include. It would work otherwise.
I can't think of any simple way to deal with this, unless the header
can be preprocessed by itself more or less standalone. Then you
could rename the header, cpp it with the output being its current
name, and the result should work inside the declare section.
Another alternative that is more work would be to extract all
of the #ifdef / #define stuff into a separate header, and include
that header outside of the esqlc declare section. If you did
something like:
defines.h:
#ifndef DEFINE_H_INCLUDED
#define DEFINE_H_INCLUDED
#ifdef BIG_STRING
... etc
#endif /* DEFINE_H_INCLUDED */
x.h:
#include <defines.h
char buf[LEN];
x.sc:
#include <defines.h
exec sql begin declare section;
exec sql include 'x.h';
exec sql end declare section;
I think that would work (haven't tested it though), and it would mean
that you would only have to change your esqlc files and not your
other .c files.
Karl |
|
|
| Back to top |
|
|
|
| Karl Schendel... |
Posted: Tue Oct 20, 2009 6:51 pm |
|
|
|
Guest
|
On Oct 20, 2009, at 6:17 AM, Mark wrote:
Quote:
Our situation is a little different. The header file in question has
to be included in non-esqlc (plain C) code so we do the following
(based on your example):
x.h:
#ifdef BIG_STRING
#define LEN 100
#else
#define LEN 200
#endif
char buf[LEN];
-----
x.sc:
exec sql begin declare section;
exec sql include 'x.h';
exec sql end declare section;
main(){}
----
esqlc -o.h -o x.sc
E_EQ0244 Syntax error in 'ifdef'.
I see, it's because the header is inside an exec sql declare
section surrounding the include. It would work otherwise.
I can't think of any simple way to deal with this, unless the header
can be preprocessed by itself more or less standalone. Then you
could rename the header, cpp it with the output being its current
name, and the result should work inside the declare section.
Another alternative that is more work would be to extract all
of the #ifdef / #define stuff into a separate header, and include
that header outside of the esqlc declare section. If you did
something like:
defines.h:
#ifndef DEFINE_H_INCLUDED
#define DEFINE_H_INCLUDED
#ifdef BIG_STRING
.... etc
#endif /* DEFINE_H_INCLUDED */
x.h:
#include <defines.h>
char buf[LEN];
x.sc:
#include <defines.h>
exec sql begin declare section;
exec sql include 'x.h';
exec sql end declare section;
I think that would work (haven't tested it though), and it would mean
that you would only have to change your esqlc files and not your
other .c files.
Karl |
|
|
| Back to top |
|
|
|
| Mark... |
Posted: Wed Oct 21, 2009 11:53 am |
|
|
|
Guest
|
On Tue, 20 Oct 2009 10:51:36 -0400, Karl Schendel
<schendel at (no spam) kbcomputer.com> wrote:
Quote: On Oct 20, 2009, at 6:17 AM, Mark wrote:
Our situation is a little different. The header file in question has
to be included in non-esqlc (plain C) code so we do the following
(based on your example):
x.h:
#ifdef BIG_STRING
#define LEN 100
#else
#define LEN 200
#endif
char buf[LEN];
-----
x.sc:
exec sql begin declare section;
exec sql include 'x.h';
exec sql end declare section;
main(){}
----
esqlc -o.h -o x.sc
E_EQ0244 Syntax error in 'ifdef'.
I see, it's because the header is inside an exec sql declare
section surrounding the include. It would work otherwise.
I can't think of any simple way to deal with this, unless the header
can be preprocessed by itself more or less standalone. Then you
could rename the header, cpp it with the output being its current
name, and the result should work inside the declare section.
I had thought of this solution but would rather avoid it as it would
be difficult to support on all the platforms that this software needs
to work on.
Quote: Another alternative that is more work would be to extract all
of the #ifdef / #define stuff into a separate header, and include
that header outside of the esqlc declare section. If you did
something like:
defines.h:
#ifndef DEFINE_H_INCLUDED
#define DEFINE_H_INCLUDED
#ifdef BIG_STRING
... etc
#endif /* DEFINE_H_INCLUDED */
x.h:
#include <defines.h
char buf[LEN];
x.sc:
#include <defines.h
exec sql begin declare section;
exec sql include 'x.h';
exec sql end declare section;
I think that would work (haven't tested it though), and it would mean
that you would only have to change your esqlc files and not your
other .c files.
This is the other solution I was trying to avoid It is slightly
more complex than this since our BIG_STRING (LEN) #define is sometimes
used in ESQL code.
I think I will just have to bite the bullet and implement the latter
solution.
--
(\__/) M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking most articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.
[Reply-to address valid until it is spammed.] |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Mon Nov 30, 2009 9:08 am
|
|