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 A581C81798 for ; Fri, 5 Jul 2013 17:50:22 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mauny.inria@gmail.com) identity=pra; client-ip=209.85.212.169; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mauny.inria@gmail.com"; x-sender="mauny.inria@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of mauny.inria@gmail.com designates 209.85.212.169 as permitted sender) identity=mailfrom; client-ip=209.85.212.169; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mauny.inria@gmail.com"; x-sender="mauny.inria@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-f169.google.com) identity=helo; client-ip=209.85.212.169; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mauny.inria@gmail.com"; x-sender="postmaster@mail-wi0-f169.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMBAPrq1lHRVdSpk2dsb2JhbABaxFlnFg4BAQEBBwsLCRQEJIIjAQEEATIBDQESJQEBAwELAQUFEg8WDwkDAgECASIBBQEODhMBBwEBh3kDCQYEm36PTIQ3Jw2ISwEFDJJFgQ4Dl0mPYD+BXYJc X-IPAS-Result: AtMBAPrq1lHRVdSpk2dsb2JhbABaxFlnFg4BAQEBBwsLCRQEJIIjAQEEATIBDQESJQEBAwELAQUFEg8WDwkDAgECASIBBQEODhMBBwEBh3kDCQYEm36PTIQ3Jw2ISwEFDJJFgQ4Dl0mPYD+BXYJc X-IronPort-AV: E=Sophos;i="4.87,1002,1363129200"; d="scan'208";a="24772541" Received: from mail-wi0-f169.google.com ([209.85.212.169]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Jul 2013 17:50:22 +0200 Received: by mail-wi0-f169.google.com with SMTP id c10so8373404wiw.0 for ; Fri, 05 Jul 2013 08:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nW5jQE9L7lRz2hOIpSyk8B5xT6gTFCOEOSsgqAVeY0U=; b=Njfwd6WW7Xo445ur2wEc2VXxHSYMIap4TtjQgDbqwCIWKisSAS4TzhBKMs+aO8WYH8 yTkGoi9P/cusiU0awhnLbMxc6MS+eek2vWOZKhNVjfa42vc4G4+C6hEFzJ3Kcnq+7j+N 3OHtWMmXPZZkdq66PiniTY9YO+wTZ/jSpOEoNZBk5ErkGiLEPvXjnyRRrBpbGeYLK7PH zmAyuOA3cShoo6tpD2roTs7sqZDgPmB/uo4gDH4c07BTB3uyv+gUVOpSlWrWw9uAlJCl NrA7ufhP1Z/Rza9Svafw9aCGr20CszNed6J/808bn3Nh9GdrdAEaGFO3SHMcd7UP1ss+ Km9g== X-Received: by 10.180.185.175 with SMTP id fd15mr23882413wic.34.1373039421496; Fri, 05 Jul 2013 08:50:21 -0700 (PDT) Received: from pcmm.ensta.fr (finiasz.net. [94.23.15.65]) by mx.google.com with ESMTPSA id s19sm41615502wik.11.2013.07.05.08.50.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Jul 2013 08:50:20 -0700 (PDT) Sender: Michel Mauny Message-ID: <51D6EB4E.9030809@inria.fr> Date: Fri, 05 Jul 2013 17:50:38 +0200 From: Michel Mauny Organization: ENSTA-ParisTech User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.6) Gecko/20070728 Thunderbird/6.0.1 Mnenhy/0.7.5.0 MIME-Version: 1.0 CC: "caml-list@inria.fr" References: <51B1EBC1.3010401@lexifi.com> <20130703154910.GA23355@annexia.org> <51D4CB15.3070400@riken.jp> <51D519D4.4030205@inria.fr> <20130704213820.GA23943@annexia.org> <51D67143.7050100@inria.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] OCaml on zLinux David Allsopp écrit/writes [05/07/2013 09:55] : > Michel Mauny wrote: >> Now, I don't think it would be a good idea to call this ocamlopt, since >> ocamlcc is an extension of ocamlc compilation chain, whereas ocamlopt is >> not. > > Is there not a case for being able to call it ocamlopt on architectures where there isn't an actual native code compiler, though? It would seem on the surface to allow OCaml to claim native code compilation on all architectures the compiler can be built on - even if on some presumably the native performance will not be as good as on others. It would be more honest to claim native code compilation through a compilation route made of ocamlc + ocamlcc. Calling this ocamlopt would let think that a set of source files together with their Makefile would just work, and this is not true. Options are different, intermediate files are different, features are different, etc. Having the same features as ocamlopt is an interesting goal, but it's too early to wrap ocamlcc in something called ocamlopt. And I'm still not sure it's a good idea at all :-) > Are there (m)any cases where you'd want to use ocamlcc instead of > ocamlopt on architectures which support the latter? One case could be the distribution of software as a single bytecode executable (no source) that could be changed into native code by OCamlCC on any architecture where ocamlc is supported. - Michel -- Michel Mauny ENSTA ParisTech