Some statistics about Fan.<div><br></div><div>Fan has a mirror directory cold which shares the same structure as src, it's the expanded code of src for distribution<div><br></div><div>For the user time</div><div>ocamlbuild cold/FanDriver.native</div>
<div>user<span class="Apple-tab-span" style="white-space:pre">  </span>0m28.494s</div><div>ocamlbuild src/FanDriver.native</div><div>user<span class="Apple-tab-span" style="white-space:pre">  </span>0m30.680s</div><div>For the system time</div>
<div>the cold directory takes</div><div>sys<span class="Apple-tab-span" style="white-space:pre">    </span>0m3.843s</div><div>while the src directory takes</div><div>sys<span class="Apple-tab-span" style="white-space:pre">      </span>0m4.657s</div>
<div><br></div><div><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 7:20 AM, Gabriel Scherer <span dir="ltr"><<a href="mailto:gabriel.scherer@gmail.com" target="_blank">gabriel.scherer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On the other hand, build systems come and go (and ./configure is like<br>
the most horrible part to add logic to in most cases), while ocamlfind<br>
has proved a reliable tool as a basis for any OCaml ecosystem so far.<br>
If I can shelve some logic there without making the tool more complex<br>
or less elegant I think that would be better for everyone.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Feb 11, 2013 at 11:56 AM, Anil Madhavapeddy <<a href="mailto:anil@recoil.org">anil@recoil.org</a>> wrote:<br>
> On 11 Feb 2013, at 10:45, Gabriel Scherer <<a href="mailto:gabriel.scherer@gmail.com">gabriel.scherer@gmail.com</a>> wrote:<br>
><br>
>> On Mon, Feb 11, 2013 at 11:31 AM, Anil Madhavapeddy <<a href="mailto:anil@recoil.org">anil@recoil.org</a>> wrote:<br>
>>> It should work just fine with ppx, and has the advantage of reducing the number of ocamlfind calls per-file (which is a considerable overhead on large projects, since it has to scan the META directories on every invocation).<br>

>><br>
>> That's of course rather orthogonal to the present discussion, but have<br>
>> you been in contact with Gerd to see if some caching solution would be<br>
>> possible? Intuitively it feels like ocamlfind could easily maintain a<br>
>> cache in /var/run/blah and only clean it on install/remove commands.<br>
>><br>
>> (An external process invocation would still make some overhead so in<br>
>> you're case you'd still have to go all the way, but that could improve<br>
>> the threshold at which such ~hacks become interesting.)<br>
><br>
> I don't think it's necessary to put this in ocamlfind, which does the job<br>
> it's designed to do very well. Just fix your build systems to run ocamlfind<br>
> at configure time, save the results, and apply them to the compiler flags<br>
> during the build phase.<br>
><br>
> -anil<br>
><br>
_______________________________________________<br>
wg-camlp4 mailing list<br>
<a href="mailto:wg-camlp4@lists.ocaml.org">wg-camlp4@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/wg-camlp4" target="_blank">http://lists.ocaml.org/listinfo/wg-camlp4</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Regards, Hongbo
</div></div>