API: can Interpreter.process() handle custom system include files?

Cling
#1

Hi all,

I’m having an issue where I’m trying to figure out how to properly include and make use of system headers that are project defined

At the bottom of my post, you can see the error messages. The interpreter seems to accept the delcaration of my custom object “testObj” however the moment i try using it, it fails.

I’m not sure if what I’m doing is not supported or wrong. Either way, could someone shed some light on this problem for me please?
Thanks

my mainfile

#include <iostream>
#include <string>

#include <cling/Interpreter/Interpreter.h>

static const std::string PATH_TO_STRUCTS = "/home/d4nf/clingTest/structs.C";
static const std::string PATH_TO_STRUCTS_SO = "/home/d4nf/clingTest/structs_C.so";
static const std::string PATH_TO_LLVM {"/home/d4nf/Downloads/Root-prefix/etc/cling"};
static const char * clingArgs[] = {"", "-std=c++11"};
int main()

{
    cling::Interpreter inter(2, clingArgs, PATH_TO_LLVM.c_str());
    inter.AddIncludePath("/home/d4nf/clingTest/sysinclude1/");
    inter.DumpIncludePath();
    inter.process("#include <someLib.h>\n"
                  "testObj foo;\n"
                  "foo.d = 66.0\n"
                  "std::cout << foo.d << std::endl;\n"
                  );
}

$ ls /home/d4nf/clingTest/sysinclude1/ someLib.h
someLib.h

[code]#ifndef someLib_H_CLING_TEST
#define someLib_H_CLING_TEST

#include
#include
#include
#include
struct testObj
{
testObj() {}
int a;
uint b;
double d;
std::string s;
//const char cs[50];
std::vector vecchar;
std::array<short,55> as;
};

#endif
[/code]

Runtime (tcling is the name of my exec)

./tcling -I /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4 -I /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/x86_64-pc-linux-gnu -I /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/backward -isystem /usr/local/include -isystem /home/d4nf/Downloads/Root-prefix/etc/cling/lib/clang/3.7.0/include -extern-c-isystem /include -extern-c-isystem /usr/include -I /home/d4nf/Downloads/root-6.04.06/interpreter/cling/include -I /home/d4nf/Downloads/Root-build/interpreter/cling/include -I /home/d4nf/clingTest/sysinclude1/ -resource-dir /home/d4nf/Downloads/Root-prefix/etc/cling/lib/clang/3.7.0 -nostdinc++ input_line_3:3:1: error: unknown type name 'foo' foo.d = 66.0 ^ input_line_3:3:4: error: cannot use dot operator on a type foo.d = 66.0 ^

#2

Hi,

The interpreter deals with two types of code blocks: statements and declarations. The latter gets passed to the clang libraries more or less unchanged, the former needs to get wrapped into an internal function which is then run. process() tries to figure out which type of code it got passes, and then takes one of the two routes.

You have passed a mixture of both: #include contains declarations, cout <<… is a statement. If you split the #include off into a separate call to process(), or even better, pass it through declare(), then it should just work.

If this doesn’t help: could you post the error messages you see?

Cheers, Axel.

#3

Hey Axel, thanks for responding

So this sounds like a bummer. If i wanted to port an existing file with existing system headers, would I be better off parsing it out myself, and feeding it to the interpreter with selective declare() and execute() calls?

Thanks

#4

Hi,

[quote] If i wanted to port an existing file[/quote]It depends what syntax the file is following. If the file is already compilable by the regular C++ compiler, you can pass its content as-is to ‘declare’ for example.

Cheers,
Philippe.

#5

Hi,

Another option might be to split the input line by line and feed each line separately into the interpreter. That is basically what happens when piping code into cling.

Cheers, Axel

#6

Hey Phillippe,

declaring my file as a header worked. Though I starting not to udnerstand how declare works since it also works with function definitions. Do Icall execute() specifically for code that needs to be compiled and run -“now”-?

Axel,
I didn’t think of runnning process() line by line, I’ll try doing that next time I encounter a similar issue. I suppose it would be safe to assume that doing so would be take abit more cpu time though…

Thanks again! I’ll be marking this thread as solved since (I think) this addressed my issue