Should the script be recompiled if any "Ocaml.sources" file is changed?

[djs55]

I've been writing some scripts which share some common code in a separate module. When I edit the script itself and run it, the code is recompiled as expected. When I edit the separate module and run the script again, it is not recompiled and the old code runs instead. I was hoping it would magically notice that the separate module had changed and recompile, like traditional scripting languages would. (I'm trying to encourage people used to python to try this)

[mjambon]

Yes, that would be a good thing. The problem in the current design is that it relies on checking file modification timestamps before doing anything expensive; and launching ocaml is considered expensive.

The steps are essentially:

1. compare timestamp of the script and compiled executable
2. split script into compilation instructions and program per se
3. run compilation instructions using ocaml

Some benchmarking would help but in my mind step 1 is very fast, step 2 can be fast if there's no need to write files, and step 3 is slow.

The list of extra sources specified by the OCaml variable Ocaml.sources is not known until step 3, which is problematic if running steps 1-2-3 systematically feels too slow.

Assuming that running ocaml each time is indeed too slow, a solution that comes to mind would be to cache the dependencies, i.e. store of copy of the Ocaml.sources in a format that is fast to parse. The list of sources would be considered up-to-date if the file that contains it is more recent than the script's source file.

[djs55]

Thanks for the detailed notes. I'll have a go at prototyping something when I get a bit more free time.

[djs55]

Oh and thanks for creating this project -- it's very useful!

[tobiasBora]

Hello,

First thank you for this great project. I'm sorry to rise this old issue, but I would love to see this feature created.

Indeed I don't think that the time problem is really relevant because someone that wants to use a fast program would compile it with oasis or something like this, there are few reasons to use Ocamlscript for that work. But ocamlscript is usefull when you want to give the priority to usability instead of speed. And here the bug with the source is really anoying… I cannot even use "ocamlfind -f" because it's not possible to give an option in a bang like #!/usr/env ocamlfind -f …

Any idea to solve this bug ?

Thank you,

Tobias.

[UnixJunkie]

this should be labelled as a bug

[mjambon]

I'm taking a look at old issues to evaluate what should be done if we decided to give ocamlscript a second life. For this particular issue, I'm leaning toward not running ocaml at all to parse the build instructions. Some possible solutions that cross my mind include:

• support a small subset of OCaml that's compatible with most legacy uses. Main benefit is backward compatibility.
• support a small subset of dune build instructions. Main benefit is to facilitate switching between dune and ocamlscript.
• support a simple key/value syntax. This would allow support for new features, such as specifying dependencies on opam packages.

[UnixJunkie]

Maybe, dune should provide a one-liner invocation, where you just want an executable for a given ocaml file which doesn't have any dune nor opam file (ocamlbuild could do that IIRC, obuild too). I had a look at the code of ocamlscript; it is fairly complex and supports many uses cases which are rarely needed I suspect (like some specific syntax extensions).