[erlang-questions] int:find_src/2, shell:try_source/2 ignore the obvious place to find source files?

[Roger Lipscombe]

Some clarifications...

On 30 May 2017 at 15:45, Roger Lipscombe <roger@REDACTED> wrote:

> When compiling some Erlang source files with mix, I discovered that it
> leaves out the abstract_code chunk.
>

or: ...when compiling some Erlang source files with mix, with custom
erlc_options that omit :debug_info, it leaves out the abstract_code chunk.

or: ...when compiling Erlang source files without 'debug_info', when the
output directory isn't just 'src' replaced with 'ebin' (i.e. rebar3 or mix
behaviour...).


> This means that rr(Mod) -- implemented in shell:read_file_records/2 --
> falls through to shell:try_source/2, which looks in the "CInf" chunk. It
> then uses the 'options'.'outdir' value and attempts to recreate the source
> path from that.
>
> That is: given the following:
>

...result from Baz:module_info(compile)...


> [{options, [{outdir, "/home/roger/Source/foo/bar/_
> build/dev/lib/baz/ebin"},
>            {i,"include"}]},
>  {version,"7.0.4"},
>  {source,"/home/roger/Source/foo/bar/baz/src/quux.erl"}]
>

(or, equivalently, the "CInf" chunk)

...it'll look for "/home/roger/Source/foo/bar/_build/dev/lib/baz/ebin/quux.erl"
> and "/home/roger/Source/foo/bar/_build/dev/lib/baz/src/quux.erl", which
> don't exist.
>
> int:find_src/2 does the same.
>
> It seems to me that the correct behaviour would be to use the 'source'
> property, if present...?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170531/ab838713/attachment.htm>