[ocaml-platform] Unique file names

Romain Bardou romain.bardou at inria.fr
Tue Mar 5 10:51:19 GMT 2013


Le 05/03/2013 11:10, Alain Frisch a écrit :
> On 03/05/2013 03:48 AM, Yaron Minsky wrote:
>> Could all of these benefits be obtained by having longer names for
>> files generated as part of the compilation (.cmx, .cmo, .cmi, etc.),
>> but keep the source file names short? i.e., one could imagine that if
>> you put "-put-in-namespace core" on the command-line to ocamlc, it
>> would generate "core_list.ml" when given the file "list.ml". The onus
>> would be on the build system to provide said flags, but it would seem
>> to simplify things thereupon.
>
> This would simplify the life of the library developer a little bit, but
> it would not really give the same benefits:
>
> - If you get an error message (or an output from a tool, such as Bisect
> or a dead code detector) with a long name, it's more difficult to find
> the corresponding source file (e.g. to look the .mli file).
>
> - You need to adapt all tools (ocamldep, ocamldoc and also third party
> tools), and this might change their interface (e.g. for ocamldoc, you
> will need to specify for each source file what's its implicit prefix).
>
> - Generic rules (e.g. in Makefiles) are more difficult to write.
>
> - You can deploy compiled files for several libraries in the same
> directory, but not the corresponding .mli files (for documentation
> purpose).

Is there a character which is not valid in module names, but which is 
valid in all file systems on all platforms, without the risk of being 
understood as a special shell character?

Let's assume '@' has this property. (Now that I think about it, '-' is 
probably a good candidate as well.) If unit "quadtree" is compiled with 
prefix "video", one could name the .cmx "video at quadtree". Then it should 
not be too hard to remove what's before the '@' in documentation and 
errors, but keep it everywhere as the internal name. To find the file, 
one would search for "*@quadtree.cmx".

You do need to adapt all tools though:
- (mandatory) check that the separator character is accepted by the tool;
- (optional) look for "*@quadtree.cmx" if "quadtree.cmx" cannot be found 
(useful for Makefiles, see below);
- (optional) change error and documentation pretty-printers.
If the latter is not done, the tools should still work, but it would 
print the long names and it might confuse the user slightly.

The Makefile issue has several solutions:
- for Makefiles which call OCamlbuild: nothing to do if OCamlbuild is 
adapted to look for prefixed files;
- for Makefiles which call ocamlfind: nothing to do if ocamlfind knows 
the actual prefixed names;
- for generic Makefiles which do not use any tool except ocamldep: maybe 
the user would have to add prefixes to dependencies, or maybe ocamldep 
or even ocaml could be adapted to make it so it is not even needed.

I'm sure there are issues with this though. In particular, searching for 
"*@quadtree.cmx" may lead to problems (takes time if there are too many 
files? what if there are several candidates?).

Cheers,

-- 
Romain Bardou


More information about the Platform mailing list