Re: Proposal: reinstate pre-built PLT for Dialyzer
Tuncer Ayaz <[email protected]> Thu, 23 Jan 2014 16:56:43 +0100
| Newsgroups | gmane.comp.lang.erlang.patches,gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <CAOvwQ4hdr6x_utxP8Jyr+AXxPG6mp-G5Q+kas3vpoeFhxgM-xw@mail.gmail.com> |
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. _______________________________________________ erlang-patches mailing list [email protected] http://erlang.org/mailman/listinfo/erlang-patches