Google Groups

Re: type_conv/ocaml4 release


Yaron Minsky Sep 6, 2012 3:35 PM
Posted in group: ocaml-core
Looping in Nick, Valentin and Sweeks.  I think they've probably seen
some of these issues before.

y

On Thu, Sep 6, 2012 at 6:34 PM, Yury Sulsky <yury....@gmail.com> wrote:
> There's a horrible hack to get around this in the build-and-install script
> to disable the creation of async.mli during the link step. Does anyone
> understand why packing Async with a cmi causes this error?
>
>
> On Thu, Sep 6, 2012 at 6:26 PM, Anil Madhavapeddy <an...@recoil.org> wrote:
>>
>> Linux/Debian gives me a ~30000 line backtrace in the Async build, using
>> separate tarballs. If you have OPAM-0.5, you can try:
>>
>> $ opam remote -add core-dev git://github.com/avsm/opam-core-pre0
>> $ opam install async
>>
>> File "lib/async.cmx", line 1, characters 0-1:
>> Error: The implementation (obtained by packing)
>>       does not match the interface lib/async.mli:
>>       Modules do not match:
>>         sig
>>           module Backpatched :
>>
>>  <25,000 lines of signature snipped>
>>
>>       Values do not match:
>>         val to_host_and_port :
>>           string ->
>>           int -> Async_extra.Import.Socket.Address.Inet.t where_to_connect
>>       is not included in
>>         val to_host_and_port :
>>           string ->
>>           int -> Async_extra.Import.Socket.Address.Inet.t where_to_connect
>>
>> Anyone else see this? Async_core,_extra,_unix seem to install ok on
>> Debian, it's just the final pack that's failing on ocaml-3.12.1.
>>
>> -anil
>>
>>
>> On 6 Sep 2012, at 15:25, Anil Madhavapeddy <an...@recoil.org> wrote:
>>
>> > The warnings are due to unused variables, mostly (such as linux_ext.ml
>> > and the Epoll module having variables in there like 'let none = 0' which are
>> > unused).  It's hard to see how to fix these without conditional compilation,
>> > or just skipping the Linux_ext module entirely).
>> >
>> > The warn_error=false flag in the environment sounds great, but isn't
>> > currently present in the tarballs.  It would be very easy to set in most
>> > packaging systems, so that's a good alternative to turning it off by default
>> > too.
>> >
>> > I'm trying a MacOS X 3.12.1 compile now to see how that goes...
>> >
>> > -anil
>> >
>> > On 6 Sep 2012, at 15:21, Yury Sulsky <yury....@gmail.com> wrote:
>> >
>> >> Thanks Anil, I'll fix the packages to disable the warnings-as-errors.
>> >> In the meantime, you should be able to build with "warn_error=false" in your
>> >> environment.
>> >> Aside from that, what warnings are you encountering?
>> >>
>> >> On Thu, Sep 6, 2012 at 5:35 PM, Anil Madhavapeddy <an...@recoil.org>
>> >> wrote:
>> >> On 8 Jul 2012, at 19:02, Markus Mottl <markus...@gmail.com> wrote:
>> >>
>> >> > On Sun, Jul 8, 2012 at 5:12 PM, Anil Madhavapeddy <an...@recoil.org>
>> >> > wrote:
>> >> >> Also, is it necessary to have warnings-are-errors enabled in the
>> >> >> released tarballs? It makes it awkward to test out new compiler versions,
>> >> >> which usually introduce new ones every release.
>> >> >
>> >> > I agree with Anil that warnings-as-errors should not be enabled in
>> >> > releases, only during development work.
>> >>
>> >>
>> >> The latest pre-release Core tarballs also fail to compile under
>> >> Homebrew/MacOS X (OCaml-4.00) due to warnings-as-errors still being
>> >> activated on release tarballs.  Have you considered disabling this on
>> >> release tarballs?
>> >>
>> >> -anil
>> >>
>> >>
>> >
>>
>