#3523: Using relative path for #include

[mdevaev]

Following #3523

[lminiero]

I'm not sure that's correct, and it's very likely to break the compilation of existing external stuff out there. Our Makefile installs headers to something like /<path>/include/janus, so the refcount.h file will be found in whatever path is passed as one to find stuff in, rather than relatively to the plugin.h folder. As such, for third party plugins (like yours, I assume), you should do different includes there, not modify this one.

In the Janus NDI plugin, for instance, we define CFLAGS like this:

CFLAGS += -I$(JANUSP)/include/janus $(shell pkg-config --cflags glib-2.0 jansson opus libcurl) -D_GNU_SOURCE -DHAVE_SRTP_2

and then the plugin includes the plugin.h file like this:

#include "plugins/plugin.h"

and it works.

[lminiero]

That said, I tried your patch with the NDI plugin and it still works, so I may be wrong about the potential impact.

[mdevaev]

It shouldn't break anything because you are giving a clear indication to the processor about the location of the header relative to the position of the current file.

I don't really like using -I$(JANUSP)/include/janus because it robs the code of the convenient and understandable prefix janus/, showing where everything comes from.

[mdevaev]

Besides, there are already similar things in your own code: https://github.com/meetecho/janus-gateway/blob/master/src/events/eventhandler.h#L100

So it just brings everything to a common approach.

[lminiero]

I don't really like using -I$(JANUSP)/include/janus

I get that, but that's what many are using, so I can't just ignore that, and if it could break things for people out there.

[mdevaev]

You don't need ignore that, please take a look at my second previous message. You're already using a relative path in other header files:

• https://github.com/meetecho/janus-gateway/blob/master/src/events/eventhandler.h#L100
• https://github.com/meetecho/janus-gateway/blob/master/src/loggers/logger.h#L83

Especially the second one. Logging is used by all plugins and it includes utils using a relative path. If logging doesn't break anything for anyone, then the relative paths for refcount won't break either, because they are at the same depth and belong to the previous directory.

You've seen for yourself that your plugin works and it doesn't break the build. In fact, if using the -I option is the only way to compile an external plugin, then you really won't break anything.

[lminiero]

Makes sense. Merging then, thanks!

[mdevaev]

Thank you!