[erlang-patches] fix include path behaviour in epp

Richard Carlsson <>
Tue Jun 14 16:18:28 CEST 2011

I thought include files were working, after I submitted a patch back in 
the R11 days, but it turns out I'm an idiot and I had only fixed the 
most important special case involving include_lib.

The following patch makes the Erlang preprocessor behave as is expected 
of a C-style preprocessor, which is to always look for include files 
relative to the parent file first, also when includes are nested:

git fetch git://github.com/richcarl/otp.git epp-include-path-fix

For example, suppose src/foo.erl contains -include("stuff/foo.hrl"), and 
the preprocessor manages to open src/stuff/foo.hrl (even though this 
subdirectory is not in the include path passed to the compiler). This 
works today, because the directory of the source file ("src" in this 
case) is always passed to the preprocessor.

However, suppose src/stuff/foo.hrl contains -include("bar.hrl") and 
src/stuff/bar.hrl exists. Without this patch, the preprocessor does not 
know to look for bar.hrl in the directory of foo.hrl, even though that 
is the first place it _ought_ to look (at least in C programming 
tradition), so the user has to make sure to explicitly pass "src/stuff" 
as part of the include path. In some build systems, this can be a royal 
pain. The patch fixes this, and should arguably not break any build that 
is not already broken by definition.

(It also means that the compiler no longer needs to pass the directory 
of the main source file as part of the include path, since that is now 
handled automatically, but that is not part of this patch.)


More information about the erlang-patches mailing list