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

Paul Fisher <>
Fri May 30 13:17:30 CEST 2008

On Fri, 2008-05-30 at 13:06 +0200, mats cronqvist wrote:
> Paul Fisher wrote:
> > 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:
> >
> >   top/project/application/source.erl
> >
> > rather than
> >
> >   top/bld/erlang/application/src/source.erl
> >
> > 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.
> >
> > ...
>   i don't remember if i already answered this; apologies if i'm rehashing.
>   seems there's a couple of issues.
>  * i think distel:guess_source_file/2 is correct; if the erl file 
> pointed to by the beam file exists, it's likely the correct one.
>  * when erlc sticks the compilation info in the beam file, it follows links.
>  * int:i/1 insists that the erl and the beam file must be either in the 
> same dir, or in adjacent src/ebin dirs.

All of this work correctly (as i noted in a follow-up message).  The
problem ultimately turned out to be the fact that the following:

-compile([export_all, debug_info]).

in the source file does *not* cause debugging information be be
generated in the beam file.  The export_all option is processed, no
problem, but not the debug_info option.  Apparently, with this
particular option, whatever is specified (or in this case the absence of
specification) on the erlc command line is taken as absolute.

I feel that this is a bug in the behavior of erlc, but it has apparently
been hashed over before with no change.


Robert Virding's First Rule:
"Any sufficiently complicated concurrent program in another language
contains an ad hoc, informally-specified, bug-ridden, slow
implementation of half of Erlang."

More information about the erlang-questions mailing list