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

[mats cronqvist]

Paul Fisher wrote:
> 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:
>
>   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.
>
> 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
> environments.
>   
  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.

  the Right Thing (tm) would be to add to the int:i API, allowing us to 
specify absolute file names for the beam and the erl files separately.

  changing distel:guess_source_file/2 to match the inanity of int:i is 
probably the second best option.

  mats