From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 19BB9BC57 for ; Fri, 22 Oct 2010 19:51:53 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYEAKZrwUxQW+UMgWdsb2JhbAChZxUBARYiIsAahUoEik2FbA X-IronPort-AV: E=Sophos;i="4.58,224,1286143200"; d="scan'208";a="74916015" Received: from lo.gmane.org ([80.91.229.12]) by mail2-smtp-roc.national.inria.fr with ESMTP; 22 Oct 2010 19:51:52 +0200 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P9LmR-0000LV-S0 for caml-list@inria.fr; Fri, 22 Oct 2010 19:51:51 +0200 Received: from avelizy-155-1-3-114.w83-199.abo.wanadoo.fr ([83.199.42.114]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Oct 2010 19:51:51 +0200 Received: from sylvain by avelizy-155-1-3-114.w83-199.abo.wanadoo.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Oct 2010 19:51:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: [ANN] oasis v0.2.0: Architecture for building OCaml libraries and applications Date: Fri, 22 Oct 2010 17:51:41 +0000 (UTC) Message-ID: References: X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: avelizy-155-1-3-114.w83-199.abo.wanadoo.fr User-Agent: slrn/pre1.0.0-18 (Linux) X-Spam: no; 0.00; le-gall:01 ocaml:01 autoconf:01 dependencies:01 dependencies:01 command-line:01 invocation:01 -help:01 command-line:01 blog:98 git:98 git:98 pager:98 wrote:01 typing:01 On 22-10-2010, bluestorm wrote: > >> Changelog and full blog post here: >> http://www.ocamlcore.com/wp/2010/10/oasis-v02-release/ > > > I've used oasis for small experiments, and I hope this project will gain > traction. > I found it perhaps still a bit rough on the dev. side : it's heavier than > just writing a simple META file, but the benefits are important (in > particular, you can avoid autoconf but still be more flexible than a simple > Makefile-only build system), and it's particularly sweet on the user side. > Have you tried the "revamped" quickstart subcommand. I am trying to make the creation of _oasis as easy as possible... If you have any suggestions to help make "lighter", I'll be happy. BTW, when you say "heavier", is it in term of complexity, of size of the generated setup.ml or something else? > I'm not convinced with the linux-installer.bin you distribute, and prefer to > build from source. oasis built flawlessly, but I first had to find the > various dependencies; in particular, the oUnit version required is newer > than the package available in either Godi or Debian, and your small > dependencies (odn, ocamlify...) cannot be found elsewhere. They're very easy > to build (thanks to... oasis), but the whole search-on-ocamlforge process is > perhaps unnecessary. > Could you provide an archive included the source of all those dependencies > that are not in both Debian (testing) and GODI ? > I'm currently using debian testing, and have needed the following files : > - ocaml-data-notation-0.0.3.tar.gz > - ocaml-expect-0.0.2.tar.gz > - ocamlify-0.0.1.tar.gz > - ounit-1.1.0.tar.gz > > (Of course, Oasis-DB will make all that a breeze ;-) And before OASIS-DB, there should be "oasis bundle", that should do exactly what you ask me. I can try to create an experimental oasis-bundle-0.2.0.tar.gz. Will you test it? > > > It's a triviality to say but I'm quite happy with the change in command-line > invocation style (OASIS -setup => oasis setup). Four small comments > regarding this : > > - when just typing "oasis", it would be nicer to directly give the help > page; darcs and git, for example, have this behavior that I find handy > > - the small message we currently have says "[..] call 'oasis -help' for > help". Wouldn't it be more consistent to "call 'oasis help'" ? I can see > that you kept the -help/--help interface for compatibility with other > command-line tools, but the subcommand-style is more consistent with the > rest of the interface > > - git and darcs automatically call a pager when producing long text output; > it would also be a nice thing to have in oasis, especially for the "oasis > manual" > > - the current behavior of subcommand help ("oasis help query") output first > the general help, then the subcommand-specific help; I think just the > subcommand-specific help would be a better output > All this seems quite reasonable. May I ask you to submit feature requests about this on the BTS? Regards Sylvain Le Gall