[Merlin-discuss] Merlin's configuration

[Sylvain Le Gall]

In OASIS we have a function that automatically generates _tags from
_oasis, generating a somehow similar tool-readable output in a plugin
will be super easy for OASIS.

We can also fine tune a lot for Merlin. We can implement new fields to
embed most of the configuration needed. If we get it right -- and if
you want -- I think it may be possible to replace .merlin by a few
fields in _oasis and reuse information from this file.

2013/11/19 Gabriel Scherer <gabriel.scherer at gmail.com>:
> 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:
>> Hello,
>>
>> 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.
>>
>> Regards
>> Sylvain
>>
>>
>>
>> 2013/11/19 Thomas Refis <thomas.refis at gmail.com>:
>>> Hi!
>>>
>>> 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
>>> say).
>>>
>>>    * * *
>>>
>>> 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
>>> configuration.
>>> 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.
>>>
>>> Cheers,
>>>
>>> Frederic and Thomas.
>>> _______________________________________________
>>> Merlin-discuss mailing list
>>> Merlin-discuss at lists.forge.ocamlcore.org
>>> https://lists.ocamlcore.org/cgi-bin/listinfo/merlin-discuss
>> _______________________________________________
>> Merlin-discuss mailing list
>> Merlin-discuss at lists.forge.ocamlcore.org
>> https://lists.ocamlcore.org/cgi-bin/listinfo/merlin-discuss