From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 8AF5581799 for ; Fri, 26 Jul 2013 13:13:16 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of wojciech.meyer@gmail.com) identity=pra; client-ip=209.85.212.170; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of wojciech.meyer@gmail.com designates 209.85.212.170 as permitted sender) identity=mailfrom; client-ip=209.85.212.170; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f170.google.com) identity=helo; client-ip=209.85.212.170; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="postmaster@mail-wi0-f170.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCAJhY8lHRVdSqjWdsb2JhbABAGoM7UKtUiTaIOoEOCBYOAQEBAQcLCwkSBiSCJAEBBAFAARsdAQMBCwYFCzsiAREBBQEcBhMbh2IBAwkGDDOac4xPgn+EVAoZJw1kh3QBBQyNIoJLBAeEBQOXX4Epin+DPxYphDs7 X-IPAS-Result: AkUCAJhY8lHRVdSqjWdsb2JhbABAGoM7UKtUiTaIOoEOCBYOAQEBAQcLCwkSBiSCJAEBBAFAARsdAQMBCwYFCzsiAREBBQEcBhMbh2IBAwkGDDOac4xPgn+EVAoZJw1kh3QBBQyNIoJLBAeEBQOXX4Epin+DPxYphDs7 X-IronPort-AV: E=Sophos;i="4.89,750,1367964000"; d="scan'208";a="27414034" Received: from mail-wi0-f170.google.com ([209.85.212.170]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 Jul 2013 13:13:15 +0200 Received: by mail-wi0-f170.google.com with SMTP id hn3so313wib.3 for ; Fri, 26 Jul 2013 04:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gvkn01SK1/vwl0Z4qQqd+wmnezgGGOp4VkpWtsY8wVM=; b=Fol7AQAWYZyRLIUkAT5FnusKhYuHcvJyRzDbAJf0iOHYweD27O/S7qmFiHoBk8q/l/ icmoDwKbSFAA4enNSu1rN5pcq9FxduT2vxWrisTu8u+ixlI+zZ+1qFf19JFDpbfqm1zc rjIMN4UC1EJiu9J22bdsKv+z7EuE2iBoKUZDlD/LaD8xNqgmbwcJbMu6xomACe234Gvz sgBXs68WtAqdYlkSb7Ezb3xooa5/eRewFBqyHma2ctcNM/cYLQaEqYK+2Ln5U7++LHA3 HDbySOtFyrnQ5g5HK+IcSxzah/KlAd9rUwhtGJRkJZ3FtS7OWDdx0KWK2kw2hoRp8A30 GWeQ== MIME-Version: 1.0 X-Received: by 10.180.108.129 with SMTP id hk1mr5319615wib.42.1374837195530; Fri, 26 Jul 2013 04:13:15 -0700 (PDT) Received: by 10.216.127.71 with HTTP; Fri, 26 Jul 2013 04:13:15 -0700 (PDT) In-Reply-To: <3BF2565DDDAA40A088D83701E3A9F0A9@erratique.ch> References: <1374669368.25411.5@samsung> <1B6BB035-9909-4F0C-9DEA-F713B977A467@ocamlpro.com> <7F8931D5-E65D-49EB-B54D-A50716F3EFDD@recoil.org> <51F0801A.5080603@riken.jp> <20130725172359.a40fdfb172b120cadab5544a@gmerlin.de> <20130725200356.GA15673@notk.org> <51F1CD6C.3050305@riken.jp> <51F2089D.4000104@riken.jp> <874nbhrddu.fsf@gmail.com> <3BF2565DDDAA40A088D83701E3A9F0A9@erratique.ch> Date: Fri, 26 Jul 2013 12:13:15 +0100 Message-ID: From: Wojciech Meyer To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: Francois Berenger , Caml List Content-Type: multipart/alternative; boundary=e89a8f3bb04fa9e65504e2683afe Subject: Re: [Caml-list] Re: ocamlbuild --e89a8f3bb04fa9e65504e2683afe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > * A wiki is not documentation. The reference document that documents the > conceptual model of ocamlbuild, the available tags and their effects > and a clear/understandable documentation of the *API* are still > missing. How does ocamlbuild build your project, how does it compute > dependencies, how does it track changes, etc. I agree we have to think, how to build up to date documentation as our top priority. Embarrassingly it's been on my plate for quite long. Now I think time is up, to update it. > * Given our struggles with myocamlbuild.ml I wonder whether the current > API is the right one or if it's just a matter of the missing > documentation. And this is from a person who has written significant > myocamlbuild.ml plugins [1,2]. If that is a sign of something my > current strategy is to switch to a mixture of shell scripts and > ocamlbuild invocations to side-step myocamlbuild.ml whenever possible. > * Easy built-in support for C stubs/libraries is missing. E.g. I'd be > glad if I hadn't to write a myocamlbuild.ml file for a simple project > like this [3]. The trouble is that OCamlbuild itself is really a build framework. It contains a lot of rules out of the box, though, but they usually all related to ocaml system, and not the external tools. Because we have no method of distributing various plugins for OCamlbuild (Coq rules, Js_of_ocaml rules, C rules, LaTeX rules etc.) it means that every project hacks it own plugin, perhaps by copy pasting from the wiki. This is un-satisfactory and a real root of the problem. Fortunately the solution for this exist, we should allow ocamlfind packages to install needed rules. We could say then: ocamlbuild -use_package js_of_ocaml.ocamlbuild Wojciech On Fri, Jul 26, 2013 at 11:48 AM, Daniel B=FCnzli wrote: > Le vendredi, 26 juillet 2013 =E0 08:25, Wojciech Meyer a =E9crit : > > I believe ocamlbuild HAS clear and sound design, more than other > > tools. In fact many ideas in ocamlbuild are novel, and interesting, this > > is the major reason I maintain it, otherwise I'd not be interested in > > doing so. > > > I completely agree. When it came out I jumped on the project --- was > burned out by a recursive make file trying to compile only things that > changed across developing libraries used by another developing project; > using just ocamlbuild, a _tags file and symlinks solved it all in a minut= e. > > However: > > * A wiki is not documentation. The reference document that documents the > conceptual model of ocamlbuild, the available tags and their effects and a > clear/understandable documentation of the *API* are still missing. How do= es > ocamlbuild build your project, how does it compute dependencies, how does > it track changes, etc. > > * Given our struggles with myocamlbuild.ml I wonder whether the current > API is the right one or if it's just a matter of the missing documentatio= n. > And this is from a person who has written significant myocamlbuild.mlplug= ins [1,2]. If that is a sign of something my current strategy is to > switch to a mixture of shell scripts and ocamlbuild invocations to > side-step myocamlbuild.ml whenever possible. > > * Easy built-in support for C stubs/libraries is missing. E.g. I'd be glad > if I hadn't to write a myocamlbuild.ml file for a simple project like > this [3]. > > Best, > > Daniel > > [1] http://brion.inria.fr/gallium/index.php/Compiling_C_with_gcc > [2] http://darcs.ocamlcore.org/ocamlunix/myocamlbuild.ml > [3] https://github.com/dbuenzli/rpng > > --e89a8f3bb04fa9e65504e2683afe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> * A wiki is not documentation. The reference doc= ument that documents the
> =A0 conceptual model of ocamlbuild,= the available tags and their effects
> =A0 and a clear/unders= tandable documentation of the *API* are still
> =A0 missing. How does ocamlbuild build your project, how does it = compute
> =A0 dependencies, how does it track changes, etc.

I agree we have to think, how to build up to date do= cumentation as our
top priority. Embarrassingly it's been on my plate for quite long.= Now I
think time is up, to update it.

&= gt; * Given our struggles with myocamlbu= ild.ml I wonder whether the current
> =A0 API is the right one or if it's just a matter of the miss= ing
> =A0 documentation. And this is from a person who has wri= tten significant
> =A0 myoc= amlbuild.ml plugins [1,2]. If that is a sign of something my
> =A0 current strategy is to switch to a mixture of shell scripts a= nd
> =A0 ocamlbuild invocations to side-step myocamlbuild.ml whenever possible.

> * Easy built-in support for C stubs/libraries is missing. E.g. I&= #39;d be
> =A0 glad if I hadn't to write a myocamlbuild.ml file for a simple project
> =A0 like this [3].

The trouble is that OCamlb= uild itself is really a build framework. It
contains a lot of rul= es out of the box, though, but they usually all
related to ocaml = system, and not the external tools. Because we have no
method of distributing various plugins for OCamlbuild (Coq rules,
Js_of_ocaml rules, C rules, LaTeX rules etc.) it means that every
project hacks it own plugin, perhaps by copy pasting from the wiki. = This is
un-satisfactory and a real root of the problem. Fortunately the soluti= on
for this exist, we should allow ocamlfind packages to install = needed
rules. We could say then:

ocamlbu= ild -use_package js_of_ocaml.ocamlbuild

Wojciech



On Fri, Jul 26, 2013 at 11:48 AM,= Daniel B=FCnzli <daniel.buenzli@erratique.ch> wro= te:
Le vendredi, 26 juillet 2013 =E0 08:25, Wojc= iech Meyer a =E9crit :
> I believe ocamlbuild HAS clear and sound design, mor= e than other
> tools. In fact many ideas in ocamlbuild are novel, and interesting, th= is
> is the major reason I maintain it, otherwise I'd not be interested= in
> doing so.


I completely agree. When it came out I jumped on the project --- was = burned out by a recursive make file trying to compile only things that chan= ged across developing libraries used by another developing project; using j= ust ocamlbuild, a _tags file and symlinks solved it all in a minute.

However:

* A wiki is not documentation. The reference document that documents the co= nceptual model of ocamlbuild, the available tags and their effects and a cl= ear/understandable documentation of the *API* are still missing. How does o= camlbuild build your project, how does it compute dependencies, how does it= track changes, etc.

* Given our struggles with myocamlbuild.ml I wonder whether the current API is the right one = or if it's just a matter of the missing documentation. And this is from= a person who has written significant myocamlbuild.ml plugins [1,2]. If that is a sign of som= ething my current strategy is to switch to a mixture of shell scripts and o= camlbuild invocations to side-step myocamlbuild.ml whenever possible.

* Easy built-in support for C stubs/libraries is missing. E.g. I'd be g= lad if I hadn't to write a myocamlbuild.ml file for a simple project like this [3].

Best,

Daniel

[1] http://brion.inria.fr/gallium/index.php/Compiling_C_wit= h_gcc
[2] http://darcs.ocamlcore.org/ocamlunix/myocamlbuild.ml
[3] https://= github.com/dbuenzli/rpng


--e89a8f3bb04fa9e65504e2683afe--