[erlang-questions] distel-mode with *.beam files separate from source

Paul Fisher <>
Fri May 23 15:26:03 CEST 2008

On Fri, 2008-05-23 at 14:44 +0200, Mats Cronqvist wrote:
> Paul Fisher wrote:
> > Did a little digging and from the bottom distel:find_source/1 certainly
> > seems to find the source file (by the
> > path /top/project/application/source.erl) correctly, so maybe there is
> > something else going one unrelated to the source tree, or possibly
> > tangentially related.  Here is the actual error I get in the
> > *erl-output* buffer that is created when I toggle on interactive:
> >
> > ** Invalid beam file or no abstract code:
> > "/top/project/application/source.erl"
>   this in all likelihood means that the beam does not contain any debug 
> info.
>   try "erlc +debug_info" (the erlc equivalent of cc -g)

I'm certain that it does have debugging information, so the error
message is really not accurately reflecting the problem, which
ultimately the fact that int:i/1 cannot find any beam file to associate
with the absolute source path name.

The problem is that distel:find_source/1 in the face of this arrangement
locates the source file as:


rather than


Then when it hands the former to the int:i/1 the interpreter does not
know how to find the source.beam file based on that location.

The core problem is that distel:get_source_file/2 should locate the
source at the latter location before the former location.  It prefers
the source file attribute in the beam file over all other alternatives
because src_from_beam/1 is first in the list that is passed to
try_srcs/1.  Works just great, except for these "out of tree" build

Seems to be that it would be preferable to simply move the result of
src_from_beam/1 to the end of the list that is handed to try_srcs/1.

BTW, I see I forgot to answer you question about if I am using GNU
autotools to do the build.  The answer is no, just a few dozen line of
gmake gooberware in our build system.


More information about the erlang-questions mailing list