[erlang-patches] fix include path behaviour in epp
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