[Merlin-discuss] Merlin's configuration
Tue Nov 19 15:57:01 GMT 2013
Re. the second point, I think trying to reimplement the build system's
job in Merlin is a dead end. You must defer to the existing build
system(s) to provide you this information.
ocamlbuild has a -show-tags option that does a fair bit of what you
want (but maybe not all: it reads _tags but does not provide as much
information as computed dynamically by the actual compilation rules;
and it returns an unspecified ocamlbuild pretty-printing format that
was planned for humans, not tools, to read). More can be implemented.
.merlin has always been a bit of a hack, duplicating information that
was already known by the build logic (plus possibly some
merlin-specific configuration that has its place). We should be
working with tool authors to *reduce* it, not extend it.
On Tue, Nov 19, 2013 at 12:26 PM, Sylvain Le Gall <sylvain at le-gall.net> wrote:
> I will be more than happy to help you on the second point to integrate
> an external process that can ask directly oasis to generate a
> configuration. I can help you on this project and even help you write
> the extension.
> 2013/11/19 Thomas Refis <thomas.refis at gmail.com>:
>> There have been some changes recently on merlin's configuration, and
>> we're also considering some more heavy changes on the syntax for the
>> .merlin file. We'd like to have people's input on this.
>> * * *
>> First we've added two new "directives": CMT and CMI, these are
>> refinements of the "B" directive, which was used to add directories to
>> the build path. The need for this is primarily felt at JaneStreet.
>> At janestreet, there is one big repository including, among others,
>> core and async. Every source directory is also a build directory but
>> the cmi for packed modules are afterwards copied to a particular lib/
>> directory at the root of this repo.
>> You then have two options to set-up your build path in merlin: add
>> only lib/, or add every source directory.
>> The first option is unsatisfactory since you won't have access to cmt
>> files (that implies no fancy source browsing), but the second is also
>> problematic. Indeed there is a lot of module name conflicts, and
>> there's no predictable way to tell which one will be choosen. That
>> results in the frequent presence of the error message "Module Foo and
>> Bar make inconsistent assumptions over interface Baz".
>> With the new directives, one can now add lib/ to the "CMI" dirs (i.e.
>> the buildpath) and every other directory to the "CMT" dirs.
>> On simpler setups, one can of course still simply use "B".
>> NB: This is not on the opam package yet, only on the git repository.
>> We should however make a new release soon (in the next two weeks I'd
>> * * *
>> We are considering moving to a more expressive syntax for the .merlin
>> files, the goal is to be more precise about which files/directories
>> require which packages/compiler flags and which do not.
>> There is two different paths we can follow here:
>> The first one is to adopt the syntax ocamlbuild uses in its _tags
>> file. This should be precise enough to express everything one would
>> ever need. Also it has the advantage of being a syntax everyone
>> already knows, and one can also imagine that at some point in the
>> future, merlin would be able to understand (at least partially) _tags
>> files whenever there is no .merlin.
>> The second one, a bit more ambitious, consist of finding a way to
>> delegate the work to external tools. That is: merlin would call an
>> (arbitrary) external process, giving it the path of the file currently
>> under edition. And that process would then output merlin's
>> That way, people could first have the configuration file in their
>> language of choice, or call a tool to generate a configuration from an
>> _tags, _oasis, ?, but would also be able to have merlin integrated in
>> their build process. For example people using a build system running
>> in "daemon" mode (jenga, OMake) could then feed it the path of the
>> file being edited, and would then receive a list of the dependencies
>> of that file, as well as compiler flags required.
>> We would like to know if you think either of this approach is useful,
>> or interesting... or not.
>> * * *
>> That's about it.
>> Frederic and Thomas.
>> Merlin-discuss mailing list
>> Merlin-discuss at lists.forge.ocamlcore.org
> Merlin-discuss mailing list
> Merlin-discuss at lists.forge.ocamlcore.org
More information about the Merlin