Build as .so - guide update on duktape.h inclusion about duktape

[svaarala]

duk_eval_string() is implemented as a macro in duktape.h. All Duktape functions are potentially implemented as macros and whether an API call is a macro or a function changes from time to time, depending on what's most convenient.

What problem are you encountering in practice?

[svaarala]

As a sidenote: when using Duktape as a .so one important note is that when you include duktape.h in the calling program, you should compile to calling program with the same DUK_OPT_xxx options you use when compiling the Duktape shared library. This is needed because some Duktape options may affect API binary compatibility (rare, but possible).

Of course, if you have no custom options, this is not an issue.

[lobingera]

Thank you.

For the problem in practice:

julia> using Duktape

julia> d = Duktape.duk_create_heap()
duk_context(Ptr{Void} @0x0bc3f740)

julia> Duktape.duk_eval_string(d,"a = 33")
ERROR: ccall: could not find function duk_eval_string in library /home/lobi/juliarepo/duktape-0.11.0/src/duktape.so
 in duk_eval_string at /home/lobi/.julia/v0.3/Duktape/src/Duktape.jl:16

I wasn't aware that the some of the APIs are defined via macro, so i implemented the interface as call to the API name. That obviously fails with duk_eval_string.

[svaarala]

Good point - I'll add a note about being sure to include duktape.h in calling files. Even if a calling program compiles and links, it might use wrong types in the call (the compiler's guess can quite easily be incorrect w.r.t. typing).

I'll reopen this until there's some additional text in the guide.

[svaarala]

This should cover the issues discussed here: aa28c89