[Caml-list] building profile cmx libraries with ocamlbuild

[Caml-list] building profile cmx libraries with ocamlbuild

[Anil Madhavapeddy]

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 %.<id>.cmx, depending on the current compilation unit's <id>.  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

Re: [Caml-list] building profile cmx libraries with ocamlbuild

[Francois Berenger]

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 %.<id>.cmx, depending on the current compilation unit's<id>.  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.