From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q1DDrRkv006687 for ; Mon, 13 Feb 2012 14:53:27 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYCADIVOU/RVdK2mGdsb2JhbABDgw2CA6pyCCIBAQEBAQgJDQcUJ4FyAQEBAwESAg8VCAEbHAIDAQsGBQsNAgIFFgsCAgkDAgECARERAQUBHBMIAQEeh1qcGQqLJkuCcIRlP4hzAgULgSSKEQ4CDwYPBAEKAwQBBQQDBAsCBwUGAQMCFBODZgkZDwIGBUGCB4EWBIhKjGiFWoE6hxE9hCA X-IronPort-AV: E=Sophos;i="4.73,412,1325458800"; d="scan'208";a="131148587" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Feb 2012 14:53:25 +0100 Received: by iaeo4 with SMTP id o4so6543996iae.27 for ; Mon, 13 Feb 2012 05:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8wSaT/7T4pmlYOBlFCyDXxRYC3VdEpQ8+hs5iGDMDWg=; b=xTjSPb0XMDGmYHoftFAcCQth8dj5hhuDYTdfQwNjDXwOzcd+hI0HKyE600gqpTM2vM RG8LX87X7DoQ0/raGTSWScZ684qqeBR49EBtUgCFHKETdvS00OhmmwTo1uJ3zq0Jqp8H PAjvOx+1R6HwuhaYeuzHT2UNhyuB5tpWoDabA= Received: by 10.50.193.195 with SMTP id hq3mr27061866igc.18.1329141204007; Mon, 13 Feb 2012 05:53:24 -0800 (PST) Received: from [192.168.1.65] (99-121-78-10.lightspeed.lnngmi.sbcglobal.net. [99.121.78.10]) by mx.google.com with ESMTPS id mr24sm27911407ibb.1.2012.02.13.05.53.22 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 05:53:23 -0800 (PST) Message-ID: <4F3915D1.6090406@gmail.com> Date: Mon, 13 Feb 2012 08:53:21 -0500 From: Edgar Friendly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <4F36D930.70008@gmail.com> <4F390A57.2020209@gmail.com> <4F39128D.7020706@lsv.ens-cachan.fr> In-Reply-To: <4F39128D.7020706@lsv.ens-cachan.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Package installation assumptions made by odb On 02/13/2012 08:39 AM, Romain Bardou wrote: > For instance, I'm currently working on a suite of tools named > like foo-feature1, foo-feature2, foo-feature3 and so on. The package > would obviously be named foo, but it does not make sense to have a > single "foo" executable. It does not make sense to have once package per > executable either. If it's all compiled at once, it's probably one package - don't split it up. I see three options: 1) name your package (in odb) foo-feature1 (ugly, but simple and works) 2) provide a dummy executable `foo` for odb to detect 3) convince me that your requirements are common enough to deserve more complexity in odb There's no need for odb to detect (or even know about) all three foo-features, it's perfectly fine for it to only know about one of them and base its decision to recompile on that one. > So I guess you need some way to override this > behavior when needed. Can odb extract this kind of information from an > _oasis file, or from a META file? I'm not very familiar with those. > odb doesn't directly access either of those files. Oasis-db extracts lots of info from _oasis files and make them available to odb in a form it understands. Findlib also handles META files on behalf of odb, although for different uses. > Regarding Melt, I'm a bit confused: you say in this mail that "its odb > package name could be melt or melt-build, depending on which part of > melt should be used to detect its installation". But in your guidelines > it is written: "Programs that are both should do both". By the way, Melt > actually installs two libraries: Melt and Latex. > At the moment, the library/executable distinction is important only for detecting installed packages. If a package is a library, it is installed only if ocamlfind knows of an ocamlfind package with the same name as the odb package. Similarly, if a package is a executable, it is installed only if `which` knows of that executable name. > Regarding the version number, if you need to define a standard I think > it would be good if this standard was to call the executable with the > "-version" option. It is, after all, the behavior of "ocamlc". This does > not work for libraries though; Libraries are not a problem - ocamlfind provides a version for them trivially (from their META file). IIRC, I wrote some code that tried to run `foo -version` to get the version of foo, but it looks like I'll have to parse the output of most programs looking for a version number. E.