Qt Creator with ecpg

[Jakob Clausen]

Hi.

I would like to use Qt Creator with ecpg, which is an embedded SQL preprocessor for C programs. It converts C programs with embedded SQL statements to normal C code by replacing the SQL invocations with special function calls.
However clang also preprocesses the code and comes with warnings of the type Unknown type name for every sql thing I use.

Can I get rid of this without disabling clang?
How should I do this? I have added the following lines to my .pro-file, which also seems a bit off.

ecpgTarget.target = cfile
ecpgTarget.commands = ecpg ../DatabaseBrowser/Database

QMAKE_EXTRA_TARGETS += ecpgTarget
PRE_TARGETDEPS = cfile

[JonB]

@Jakob-Clausen
If you put something like

#if    0
EXEC ...
#endif

around those lines, does that allow them to get through without upsetting clang/the IDE? Technically you're only allowed to put invalid C++ code even inside #if blocks, but sometimes tools just ignore it when false.

If that works, you would need to have a symbol or expression you can test there which is false in editor but true while your SQL preprocessor is running. I'm sure you can find one --- it probably defines something itself which you could use.

[Pl45m4]

@Jakob-Clausen said in Qt Creator with ecpg:

Unknown type name for every sql thing I use.

I have not any knowledge of ecpg, but are you really supposed to write it like this?!
Doesn't ecpg need to run before you put that code in your cpp file?!
As far as I understand, you need to pass some special .pcg file to ecpg and it outputs a C code file. So writing these SQL commands in the c / cpp file directly might not work?!

[Jakob Clausen]

@Pl45m4 That is correct.
The code that I have shown is from the .pcg file, and then ecpg preprocesses the code and generates a .c file, which can be compiled normally. The .pcg file is a c-file with some special ecpg-sql commands that are replaced by ecpg.
But I would still like to use clang on the .pcg file, and then I get these warnings .

[Christian Ehrlicher]

@Jakob-Clausen said in Qt Creator with ecpg:

But I would still like to use clang on the .pcg file, and then I get these warnings .

How should this work when there are special ecpg commands which are no c/c++ constructs in there?

[JonB]

@Jakob-Clausen
If you put something like

#if    0
EXEC ...
#endif

around those lines, does that allow them to get through without upsetting clang/the IDE? Technically you're only allowed to put invalid C++ code even inside #if blocks, but sometimes tools just ignore it when false.

If that works, you would need to have a symbol or expression you can test there which is false in editor but true while your SQL preprocessor is running. I'm sure you can find one --- it probably defines something itself which you could use.

[Jakob Clausen]

@Christian-Ehrlicher It is ecpg commands mixed with ordinary c-code. So I would like to suppress that particular warning for that particular file.

[JonB]

@Jakob-Clausen
He & we know this. That doesn't make it possible for a C++ parser to parse the file correctly. And as you can see your warnings are pretty generic, you want to suppress "Unknown type" or "Missing ';'"?

[Jakob Clausen]

@JonB I see your point. Could I disable clang for .pgc-files while still have some syntax highlighting? And then keep it as it is with .cpp files?

[JonB]

@Jakob-Clausen That I don't know. But did you give a try to my earlier #if... suggestion?

[Jakob Clausen]

@JonB I did. And it did work. But I get no syntax highligthing. Maybe thats as good as it gets. So thank you for the input. I think I'll go with that.

[JonB]

@Jakob-Clausen said in Qt Creator with ecpg:

But I get no syntax highligthing

No syntax highlighting on what? On the EXEC SQL ... lines? That is the intention, else you will get the error! Qt Creator/clang is not going to "syntax highlight" those lines because they are not parseable C++! Not sure what else you would expect? I trust you do not mean that the rest of the C++ code, outside of the #if 0 blocks, lose their C++ highlighting?

[Jakob Clausen]

@JonB No. You are right. Thank you.