Inlcudes issue about edts

[define-null]

Not an issue, my fault.

[tjarvstrand]

This is because of where the erlang compiler looks for include-files. By default it only searches for the file relative to "." and the location of the file it's compiling. EDTS does not any directories in addition to this.

The below should work if some_lib is located one of the project's configured lib-dirs:

-include_lib("some_lib/include/other.hrl").

The below will only work if some.hrl is located in the same directory as the file where it is included, or if it's in the directory that is the current working directory at compile-time (bad idea to rely on this!).

-include("some.hrl").

The below always works since other.hrl will be found relative to the module location:

-include("../some.hrl").

[define-null]

There are situations, when hrl file is still highlighed as missing, but M - . works fine. Sometimes it is not highlighted. Probably I should find out the test case which reproduce it.

[define-null]

As far as I know according to otp principles hrl files should be located in include dir so it would be great if edts will have a chance to find them according to rebar information (include section in erl_opts) or in config.

-include("../include/some.hrl").

Ofcourse example above always works, but it's a bad practice in my opinion.

[tjarvstrand]

Yes, M-. only parses part of the code and does not rely on the module being compiled/loaded on the project's node.

Putting hrl-files in the include-folder is the convention, but you should depend as little as possible on special configurations of your build system. In other words, alway use

-include_lib("some_lib/include/other.hrl").

or

-include("../include/other.hrl").

and never

-include("other.hrl").

Because you can never depend on that different build systems (rebar, EDTS, flymake, peoples own make-files etc.) will work in the same way. The first two examples should always work, no matter what build-system you use.

i will think about it, but I believe that the current workings are good, and that if I change it I will just hide people's compilation errors.

[define-null]

As far as include-folder is the convention i think

-include("other.hrl").

should be used to point to hrl file in the include dir of application and if you want to point to hrl in the current dir or any other you can always make it explicit:

-include("./other.hrl").

But it's your turn to decide)))

p.s. So as you see I fully agree about the part of deps aplications and other build systems, the only thing I wanna change - relative paths in local app.

[tjarvstrand]

Sorry, I made a mistake earlier.

There is a widespread (albeit undocumented) Erlang convention to put application-internal header-files (eg. containing records that should only be used inside the application) in the src directory and only keep header-files that are for "external" use in the include directory.

Thus

-include("other.hrl").

can be used to include application-internal headers, but should not be used for ones in the include-directory, IMHO.