[erlang-patches] [PATCH] Updated erlang-flymake to recognize "deps" directory

Klas Johansson <>
Sat Dec 10 11:17:49 CET 2011


Hi,

On Wed, Dec 7, 2011 at 8:46 AM, Kevin Albrecht <> wrote:
> Here is my updated patch suggestion based on input. I fixed a typo in
> the deps path and improved my commit message. I considered
> additionally adding deps/*/include, deps/*/ebin, and deps/*/src as
> include directories, but erlc's -I command line option does not
> support wildcards, so this is not possible.

You could expand the wildcards on the elisp side, using
file-expand-wildcards.  From the elisp man pages:

    file-expand-wildcards is a compiled Lisp function in `files.el'.

    (file-expand-wildcards PATTERN &optional FULL)

    Expand wildcard pattern PATTERN.
    This returns a list of file names which match the pattern.

    If PATTERN is written as an absolute file name,
    the values are absolute also.

    If PATTERN is written as a relative file name, it is interpreted
    relative to the current default directory, `default-directory'.
    The file names returned are normally also relative to the current
    default directory.  However, if FULL is non-nil, they are absolute.

I wouldn't add deps/*/src as deps/*/ebin as *include* dirs, but rather add:

- deps/*/include to erlang-flymake-get-include-dirs
- deps/*/ebin to erlang-flymake-get-code-path-dirs

I noticed a quirk with rebar and dependencies a while back.  Let's say
application A depends on application B which depends on application C.
 Also assume A uses include_lib to include a file from B and that B
uses include_lib to include a file from C.  Last time I checked (some
weeks ago) rebar didn't resolve these transitive dependencies when
running eunit tests (i.e. the code path to C wouldn't automatically be
added to the test runs for A), so I had to make A dependent of C.


Cheers,
Klas


More information about the erlang-patches mailing list