[erlang-questions] distel-mode with *.beam files separate from source
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:
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