From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <marek@xivilization.net>
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by sympa.inria.fr (Postfix) with ESMTPS id C9A7A7EE20
	for <caml-list@sympa.inria.fr>; Wed, 14 Nov 2012 17:36:47 +0100 (CET)
Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  marek@xivilization.net) identity=pra; client-ip=178.63.18.39;
  receiver=mail4-smtp-sop.national.inria.fr;
  envelope-from="marek@xivilization.net";
  x-sender="marek@xivilization.net";
  x-conformance=sidf_compatible
Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of
  marek@xivilization.net designates 178.63.18.39 as permitted
  sender) identity=mailfrom; client-ip=178.63.18.39;
  receiver=mail4-smtp-sop.national.inria.fr;
  envelope-from="marek@xivilization.net";
  x-sender="marek@xivilization.net";
  x-conformance=sidf_compatible; x-record-type="v=spf1"
Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@coaxial.xivilization.net) identity=helo;
  client-ip=178.63.18.39;
  receiver=mail4-smtp-sop.national.inria.fr;
  envelope-from="marek@xivilization.net";
  x-sender="postmaster@coaxial.xivilization.net";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAFbHo1CyPxIn/2dsb2JhbABEwz6BCIIeAQEEAQw0AQE4BAsLRlcZG4dpCgenT4Q3AQV1ji0GjC0FgwCDJ5V+gR2PJ4Jw
X-IronPort-AV: E=Sophos;i="4.83,251,1352070000"; 
   d="scan'208";a="162471830"
Received: from coaxial.xivilization.net ([178.63.18.39])
  by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 14 Nov 2012 17:36:47 +0100
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xivilization.net; s=xiv;
	h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=2j8HLfsVPBvsr3d1fumdy5r95zAGlv7+M80wtCOCfAY=;
	b=XwJNky6pRi3z/i6pzGO4UKYN4pq3sdxQ0O28Th4yrn5gzgeYR6JYUKsSjJkKwXrpR2i/X/R8csIoV6HuRe9sAzBmrwWIK0s5JDFcQS8sZohkmtYYNrW+4185EhzhWFRf;
Received: from ppp-93-104-184-234.dynamic.mnet-online.de ([93.104.184.234] helo=localhost.localdomain)
	by coaxial.xivilization.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
	(Exim 4.72)
	(envelope-from <marek@xivilization.net>)
	id 1TYfxG-0001JX-Ck
	for caml-list@inria.fr; Wed, 14 Nov 2012 17:36:46 +0100
Date: Wed, 14 Nov 2012 17:36:43 +0100
From: Marek Kubica <marek@xivilization.net>
To: caml-list@inria.fr
Message-ID: <20121114173643.34e1e4c2@xivilization.net>
In-Reply-To: <50A3AD8F.7020301@etorok.net>
References: <20121114124355.7e8ca762@xivilization.net>
	<50A3AD8F.7020301@etorok.net>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Caml-list] Preferred layout for new packages

Hi,

On Wed, 14 Nov 2012 16:41:19 +0200
T=F6r=F6k Edwin <edwin+ml-ocaml@etorok.net> wrote:

> OMake has some nice features for more complex projects, for example
> polling the FS for changes and automatically rebuilding.

Yes, but nowadays I can just use inotifywait in a loop which
essentially does the same but frees me from dealing with its OMakefile
syntax which I did not like very much.

> > What is the state of the art
> > solution?
>=20
> Try oasis, it provides a good starting point:
> http://oasis.forge.ocamlcore.org/
>=20
> You can later extend it with custom rules in _tags/myocamlbuild.ml if
> needed.

Great, this looks really good. The file format seems simple and
intuitive.

> > 3. Stdlib: I don't mind depending on batteries and/or core, are
> > there any reasons against? Especially in the unit tests it drove me
> > nuts that I wasn't able to display results without writing
> > printers, and I know batteries has at least a generic printer.
>=20
> Are you writing an application or a library?
> If you're writing a library it is probably better to avoid unneeded
> dependencies, or provide optional subpackages (see the recent thread
> about pgocaml.batteries). That way people who don't use
> batteries/core can still use your package.

I am writing a library (and also a command line program as a thin
wrapper over the library). As you said, in optional parts like tests I
might want to use core/batteries. Also, kind-of depends on whether they
offer other things that I might need or not. Not planning on reinventing
the wheel.

regards,
Marek