|
The expected behaviour of a C-style preprocessor (such as Erlang's epp) is
to allow a header file to include another header file in the same directory
even though that directory is not explicitly in the include path, and even
if the actual include path might reference another directory containing a
file with the same name. For example, if src/foo.erl explicitly includes
"../include/foo.hrl", then foo.hrl should be able to include "bar.hrl" in
that same directory even though "../include" might not be in the search
path, and even if another file named bar.hrl could be found using the search
path it should not override the one in the same directory as foo.hrl.
In Erlang, the most common situation is that a user of an installed
application includes a main public header file using include_lib
("appname/include/foo.hrl") and that file includes a secondary header file
"bar.hrl". However, if it does this using include_lib, it causes a
bootstrapping problem - in the build environment for the application itself,
the application is not necessarily found by name. On the other hand, if
foo.hrl uses a plain include, then bar.hrl might be found when the
application is built (if explicit paths are set in the makefils) but not
later on when a user includes the main header file of the installed
application via include_lib.
By making -include always look in the directory of the current file before
it uses the search path, this problem is remedied, and include directives
behave in a more intuitive way.
This completes a partial fix in R11 that only worked for include_lib().
|
