[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] breaking up cstruct packages

  • To: Hannes Mehnert <hannes@xxxxxxxxxxx>
  • From: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • Date: Thu, 3 Nov 2016 13:01:57 +0000
  • Cc: mirageos-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 03 Nov 2016 13:02:03 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=recoil.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=AbDTxSeLn9Q9wxxbXaiFMilTFonAhvEJdrbwgN5ZRGtZiV4knKv q5+UVV9RaQMNKKKPXOBEwr2j1kV7WBvIfWp0TdtWam8jQ24HSECLqOjz4/hthEtv j0aMgcy8T5UkYnuMLkdjgD7uZBXgj4EPPvCAiCu6BxJhLpEWB28QD+3k=
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

On 3 Nov 2016, at 12:57, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> On 03/11/2016 12:19, Anil Madhavapeddy wrote:
>> I'm porting cstruct opam packages to topkg, and need to make a backwards 
>> incompatible change to the ocamlfind layout.  It is currently:
>> cstruct
>> cstruct.lwt
>> cstruct.ppx
>> cstruct.unix
>> I propose to change these ocamlfind packages to 
>> cstruct
>> cstruct-lwt
>> cstruct-ppx
>> cstruct-unix
>> so that they are the same as the ocamlfind layout.  This also makes it 
>> possible to have different version constraints on each package.  The 
>> specific bug I am trying to fix is that "cstruct.async" is blocking OCaml 
>> 4.04 support until the upstream Async release comes out, and I would like to 
>> get the core package building and released as soon as possible.  With the 
>> new scheme there is much looser coupling among the dependencies, at the cost 
>> of rewiring all the existing users to a new ocamlfind syntax.
> You mean cstruct.ppx here, instead of cstruct.async, or?

No Async as well as PPX -- neither work on 4.04 out of the box until ported, 
but the core library works just fine of course.  I'd like more trunk testing of 
core libraries on the main OCaml, so it could perhaps even be included in 
upstream regression testing for the compiler rather than requiring release-time 

>> Thoughts welcome!  This would be a bump to Cstruct 3.0 to account for the 
>> large scale renaming.
> Sounds good to me.  While at it, can the generated to/of string
> functions of %%cenum be optional, please (by having a [@@string],
> similar to [@@sexp] -- where sexp needs to imply string since it's
> implementation uses to/of_string)?

Sure, can you throw me an issue on ocaml-cstruct so I dont forget this? Makes 
sense to not overly depend on the compiler smarts here.


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.