From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 2CE507ED26 for ; Fri, 15 Jun 2012 02:46:17 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEBAIKE2k+GoCGhmWdsb2JhbABFtWABAQEBAQgLCxsnghgBAQUnEUARCxgJFg8JAwIBAgFFEwgBAYYNgXq6D4sygnaDGwOIP4xigRKEQo0XgVA X-IronPort-AV: E=Sophos;i="4.75,774,1330902000"; d="scan'208";a="147746282" Received: from postman1.riken.jp (HELO postman.riken.jp) ([134.160.33.161]) by mail4-smtp-sop.national.inria.fr with ESMTP; 15 Jun 2012 02:46:15 +0200 Received: from postman.riken.jp (postman1.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id B0DAF32C00AC for ; Fri, 15 Jun 2012 09:46:12 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id 7893A32A008C for ; Fri, 15 Jun 2012 09:46:12 +0900 (JST) Message-ID: <4FDA85D4.9070903@riken.jp> Date: Fri, 15 Jun 2012 09:46:12 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: caml-list@inria.fr References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.15.3917 Subject: Re: [Caml-list] building profile cmx libraries with ocamlbuild On 06/15/2012 12:47 AM, Anil Madhavapeddy wrote: > Hi, > > I'm shifting our build system to produce profiling versions of libraries, and am using ocamlbuild's %.p.cmx target. It seems to interact oddly with cross-module inlining, and I wanted to check if this was a bug or a misunderstanding on my part. > > Consider two modules: foo.ml, bar.ml, and Bar has references to Foo. If I compile 'ocamlbuild bar.cmx', then foo.cmx will be built first and be available to ocamlopt when bar.cmx is being produced. > > However, if I compile 'ocamlbuild bar.p.cmx', the rule generates 'foo.p.cmx', which is not picked up as a valid CMX for the Foo module. This normally silently works, except in the case when Foo and Bar are being packed into a module, and the compiler then complains that bar.cmx was compiled without access to foo.cmx. > > So what is the best way to fix the rule? I could put in an artificial dependency on %.p.cmx->%.cmx to ensure that there is always something picked up. Alternatively, ocamlopt's compileenv could be modified to also look for %..cmx, depending on the current compilation unit's. Or is there a third, correct way to build a profiled library that I'm missing? > > Incidentally, I've also had to add a custom build rule for %.d.cmx, which appears to be missing. %.d.cma exists, and %.p.cmx, but not %.p.cma (because ocamlcp is not supported by ocamlbuild, which is fine), but is the lack of a '-g' option for native code libraries an oversight, or unnecessary for some other reason? > > -Anil, from the darkest depths of myocamlbuild.ml Sorry, this does not exactly answer your question but, if you are using oasis, just turn profile="false" to profile="true" in setup.data to turn debugging on (using gprof). Regards, F.