Re: [Caml-list] META file standards for ppx extensions

[Gerd Stolpmann <info@gerd-stolpmann.de>]

[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]

Am Freitag, den 10.04.2015, 01:06 +0200 schrieb Daniel Bünzli:
> Le vendredi, 10 avril 2015 à 00:21, Gerd Stolpmann a écrit :
> > No - you'd need to parse the command and watch out for -pp and -ppx
> > options.
> 
> […]
> > I think the -ppx option is ignored by ocamlc if there is no module
> > source, so ocamlfind doesn't care about it.
> 
> That seems quite brittle and unprecise 

No, it is well-defined.

> and are things that get in the way/you have to consider when you need to debug build systems.

Why is it in the way? In a build system you compile normally module by
module, and separate linking out, but only because you can then specify
the options module by module, or by linking situation. However, ocamlc
already offers a superset of this, and why should ocamlfind restrict
that? It has always been the philosophy of findlib that it supports
everything ocamlc does, and in the same way, i.e. you can turn

ocamlc <options>

always into

ocamlfind ocamlc <options>

only that you have additional options. This philosophy is part of the
success story of findlib, and I won't change that.

> It seems to me that OCaml's build rules are already sufficiently complex so that the tool that is supposed to help us to manage them doesn't introduce more noise in the system.
> 
> More specifically I think that most build system developers out there would agree that having a clear ocamlfind sub-command that allows us to query the *exact* flags a package is supposed to provide us along the well defined phases: pre-processing, compilation and linking in the native and bytecode dimensions would be of great help in general.  

I think you are hunting a ghost animal. The ocamlfind wrapper is fast
enough that you can ignore it, and skipping it will only so minimally
speed up builds that it is not worth doing it.

If you want to develop something in this direction, I'd suggest a
different path, namely a new driver for the ocaml compilers that runs as
a server, and that communicates with the build system over a pipe. Also,
what we can talk about is that ocamlfind functionality is completely
available as library (as of now there is only package lookup in the
library, but not command construction). This would allow it to link it
into your build system, and simply call the functions directly. But as
said, alone this will not be the big accelerator, only in conjunction
with a true compile server.

Gerd

> Would you maybe consider implementing something along these lines ?  
> 
> Best,
> 
> Daniel
> 
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]