the #include directives in the generated code do no use the folder structor of the support lib

[Harald]

currently, generated code has, for example in case of jni bindings, this include statement

#include "djinni_support.hpp"

but I think it should be

#include <djinni/jni/djinni_support.hpp>

so it is possible to not having to add various include directives, or just use standard include if the support lib is installed into the file system / root system

alternative opinions are welcome !

[jothepro]

This seems to make sense. I wonder if we should introduce this as a breaking change or if it should be configurable as a parameter, so existing build setups won't fail.

[Harald]

I think this is a very good question, one that might pop up from time to time ....

one side of me says: add an option
an other side says: no options, it will become too many execution paths and more code to maintain, complexity will add up

let us thing a moment about that, and maybe collect more information

-
for the very subject, I am not sure that we break too much, because, basically what we would do is saying: please use default include path (to include) , the rest is picked up automatically , and instead of 3 you have just 1 include path to manage.

[Paulo Coutinho]

Hi,

I think the same thing. It need be a more specific path for djinni, because sometimes it has conflicts with other headers.

But it need be applied to all support lib.

And in my opinion you can use quotes:

#include "djinni/jni/djinni_support.hpp"

Because it is not in the compiler/system path, but custom/app path.

https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

Thanks.

[Harald]

The compiler will find it anyway, its just a question of the search order,
If the support lib comes with a conan or hunter package, what it sooner or later will, or ist installed what it could be, its not a " path first.
But in general I do not have any strong preferences about <or", once we will have that implemented, doing the one or the other will be easy.

[Paulo Coutinho]

Sure.

With quotes will be compatible with generated code by djinni:

I think (again, in my opinion) that we can make it more similar.

What need for this? Can i make a PR for this?

[Harald]

Sure Paulo!
Contributions are very welcome!

Please see https://djinni.xlcpp.dev/contributing/

[Harald]

I just found out , this is already possible,

the --jni-base-lib-include-prefix can do that.

djinni ..... --jni-base-lib-include-prefix djinni/jni/ ....
will generate
#include "djinni/jni/djinni_support.hpp"

But the documentation of that option is not optimal, so that should be improved.
So I add the documentation label

however, since this plays together with
cross-language-cpp/djinni-support-lib#3
a different default value would very likely be beneficial ...
therefore the enhancement label

[Harald]

I created now a PR for this issue, since changing it should not break any existing setup, just an adoption of the include
and 2 different include paths go no into one, beside that, code details do not change.
Also, if the previous behaviour is wanted, it can easily be restored by setting --jni-base-lib-include-prefix

if there are any opinions on that please share them. Otherwise , when the tests are adopted, the change will go into main