[erlang-questions] [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer

[Tuncer Ayaz]

On Thu, Jan 23, 2014 at 4:31 PM, Sean Cribbs wrote:
> On Thu, Jan 23, 2014 at 9:18 AM, Tuncer Ayaz wrote:
>>
>>
>> How do you define the standard library? I mean, why not include all
>> libs/apps?
>
>
> Yes, that is exactly what I mean. Anything that ships with OTP and
> is not explicitly disabled or skipped by the build process should be
> included.
>
>>
>>
>> I usually build a comprehensive PLT for each OTP release and
>> unfortunately that uncovers type errors which should not be shipped
>> in a release :(.
>>
>
> And we should be fixing those! :D

See https://github.com/erlang/otp/pull/166.

Unfortunately the one issue that needs discussion and decision-making
by the OTP team has been reported and gone unfixed for a couple
releases.
See http://erlang.org/pipermail/erlang-bugs/2013-September/003765.html

>> From what I recall, a PLT references the beam files with absolute
>> filenames. This might pose a problem you'd have to solve first.
>
>
> Thank you for pointing that out. I'll look into that.

BTW, assuming this gets off the ground, would you suggest distributing
the PLT with the tarball or in the git tree? I think the src tarball
and maybe a separate tarball make more sense. For reference, my local
R16B03 PLT is 4MB. This would also be in line with other generated
files like configure scripts (what's generated vs what's edited). In
the git tree it would only make sense to be included in a tagged tree,
but that may be confusing, so release tarballs make the most sense to
me.