From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q28LRP6T004439 for ; Thu, 8 Mar 2012 22:27:25 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuABACwjWU/RVaC2kGdsb2JhbABDtSEIIgEBAQEJCQ0HFAQjggoBAQEDARICLAE4AQMBCwEFBQs7IhIBBQEcBhMUDoVvgXQFnHcKjmWFIYkzAQULkEsElUWHcYZJPYFUgjGBWw X-IronPort-AV: E=Sophos;i="4.73,553,1325458800"; d="scan'208";a="148325068" Received: from mail-gy0-f182.google.com ([209.85.160.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Mar 2012 22:27:22 +0100 Received: by ghrr20 with SMTP id r20so774648ghr.27 for ; Thu, 08 Mar 2012 13:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lP3WIZwrp3fVWF3JD6ZGDOo6HBtvEcoUvrb611BBNhQ=; b=zuxX/RR2Ha58+r3WzLQYyH957DkFtPlkgUAbhGD92+NoYsDLcquQAQh/DgIoRay9cy Aihjdf2g514q4spYZme0MKLUAemrS29hdw7G3zfZQwoPA2Zod1eVf3Cbqjl3HIlFDCR5 osG1fL2Oc5MGU6pO2gGyMbTPHgYreqQdE05Q6211nMkgcv2ZHX+/vsQBnAG+id36k2yY trFvlART75cuGLSjJfkNU+Q2vf6oF+ABVYFaAuGq6z3B2MM2+eUELWArDSZlEe2o+opc Me4dDVZ/NoVD+E1oeJUHa8PbRrdrjo83LXVLHZhQA7TN1fiLPsFIvSKo+t/OcbyohitZ 5urg== MIME-Version: 1.0 Received: by 10.50.186.161 with SMTP id fl1mr9055164igc.44.1331242040619; Thu, 08 Mar 2012 13:27:20 -0800 (PST) Sender: gildor478@gmail.com Received: by 10.42.169.135 with HTTP; Thu, 8 Mar 2012 13:27:20 -0800 (PST) In-Reply-To: <1ACBE325A80144A4885B44685F6E9028@erratique.ch> References: <1991A512A37E49ACA5AAD30A38D628BF@erratique.ch> <1ACBE325A80144A4885B44685F6E9028@erratique.ch> Date: Thu, 8 Mar 2012 22:27:20 +0100 X-Google-Sender-Auth: WhJ_UvykAs9gLKaqWeHaaE8I6c0 Message-ID: From: Sylvain Le Gall To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q28LRP6T004439 Subject: Re: [Caml-list] Re: oasis packaging questions Hi, 2012/3/8 Daniel Bünzli : >> OK, so first of all you are talking about the odb/GODI/oasis-db level. >> OASIS itself is not meant to handle that directly. There will be a >> plugin "oasis-db" that will allow you to do "oasis install xmlm" and >> "oasis uninstalll xmlm" and fetch the source from >> http://oasis.ocamlcore.org but this is the future and this won't be >> the core oasis system. You can have a look at odb that allow you to >> already do that after having uploaded your package to >> http://oasis.ocamlcore.org. >> >> Concerning the ocamlfind install + documentation. I understand you but >> it is technically not feasible right now (AFAIK). Simple fact: >> ocamlfind cannot install files in subdirectories. > > > Ok interesting fact. This raises a few comments/questions. > > 1) You tell me that's none of oasis business. But setup.ml sports a -install option so you actually deal with installing things (even if its via ocamlfind). More than that the examples I saw for Document sections are along the lines of copying things to a specific $htmldir so oasis seems to deal with that... At least that's the place where *something* should happen so that the right info gets to the right place. OK, you got me on this. Technically, it is possible to do it using oasis. We just have to define a dynamic variable that will contain the directory ocamlfind choose to install the library. It is not trivial to do and you can set it without enforcing $htmldir. You have to use "ocaml setup.ml --docdir '$pkg_XYZ_installdir'". Let say that if you just use $htmldir, it will help whatever packaging system that cooperate with oasis to enforce it in the future. To be honest, if it was the only problem I have to solve, I'll be happy to spend hours on that. > > 2) How does godi et al. handle documentation ? I know for sure that odb doesn't do anything about it. It does it the right way ;-) $ ls /opt/godi/doc/ apps-oasis godi-lablgl godi-ocaml-fileutils godi-react apps-ocamlify godi-lablgtk2 godi-ocamlgraph godi-sexplib GODI godi-lwt godi-ocamlmakefile godi-sqlite3 godi-cryptgps godi-menhir godi-ocamlnet godi-tools godi-cryptokit godi-ocaml godi-ocaml-text godi-type-conv godi-extlib godi-ocaml-data-notation godi-ounit godi-zip godi-findlib godi-ocaml-expect godi-pcre ocsigen $ ls /opt/godi/doc/apps-oasis/ AUTHORS.txt CHANGES.txt COPYING.txt MANUAL.mkd oasis README.txt (oasis contains the html documentation of the API). > 3) Would ocamlfind consider extending its approach to be able to install files in subdirectories ? > > I really think that easy access to README, CHANGES and other bits like ocamldoc generated doc is paramount in a good package system since you don't get to see the tarballs anymore. I try to do my best and spend long hours on the documentation of the things I distribute (doesn't mean it's perfect, I sometimes don't understand what I wrote myself...), I want them to be somehow easily accessible (and easily destroyable). > > Can't we agree on something at that level ? I would probably object to have html documentation in the $SITELIB of findlib. However, if there is something to distribute and that should go in $SITELIB/pkg, it should be a .odoc (compiled ocamldoc generated using -dump). Among all the possible format, I think this is the easiest one to use if you want to cooperate with TypeRex (or Cameleon). Moreover, starting with this .odoc you can generate html documentation or whatever ocamldoc generator you have at hand. I think a CHANGES/README is light enough to be in $SITELIB as well. But all this need to be more widely discuss (with OCamlPro for TypeRex, Maxence for .odoc/Cameleon, Gerd for ocamlfind and the rest of the community to have a real agreement on this point). > P.S. Btw. setup.ml -install should maybe also install the _oasis files. Well _oasis can also go there, even though it will be a little bit a duplicate with META... Cheers Sylvain