[wg-camlp4] benchmarks

[Gabriel Scherer]

On the other hand, build systems come and go (and ./configure is like
the most horrible part to add logic to in most cases), while ocamlfind
has proved a reliable tool as a basis for any OCaml ecosystem so far.
If I can shelve some logic there without making the tool more complex
or less elegant I think that would be better for everyone.

On Mon, Feb 11, 2013 at 11:56 AM, Anil Madhavapeddy <anil at recoil.org> wrote:
> On 11 Feb 2013, at 10:45, Gabriel Scherer <gabriel.scherer at gmail.com> wrote:
>
>> On Mon, Feb 11, 2013 at 11:31 AM, Anil Madhavapeddy <anil at recoil.org> wrote:
>>> 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).
>>
>> That's of course rather orthogonal to the present discussion, but have
>> you been in contact with Gerd to see if some caching solution would be
>> possible? Intuitively it feels like ocamlfind could easily maintain a
>> cache in /var/run/blah and only clean it on install/remove commands.
>>
>> (An external process invocation would still make some overhead so in
>> you're case you'd still have to go all the way, but that could improve
>> the threshold at which such ~hacks become interesting.)
>
> I don't think it's necessary to put this in ocamlfind, which does the job
> it's designed to do very well. Just fix your build systems to run ocamlfind
> at configure time, save the results, and apply them to the compiler flags
> during the build phase.
>
> -anil
>