Mangle compilation units of dune generated modules

[rgrinberg]

As discussed, we want to minimize the chance of compilation units of libraries colliding with the executables. For dune generated exe's (as opposed to user defined ones), I think we can change the scheme unilaterally without the user noticing.

I've opted for some fairly simple mangling for these modules. Just to make sure we don't introduce unnecessary recompilation.

[rgrinberg]

@diml I've added a slightly simpler name mangling scheme based on the project name and the source dir. This seems safe enough and is friendlier to incremental compilation. Also, we don't need the linking closure to just compute the module names of executables.

[ghost]

Agreed for not using the closed list of modules. Though using the project name feels a bit odd. In particular, as we discussed recently in another PR it's possible that we'll allow project names to not be unique at some point.

As long as we have __ in the prefix, this would only break if someone was using __ in a library name, which is very unlikely. What about always using dune__exe as prefix? Or bin__prefix (this is similar to what we use inside Jane Street).

[ghost]

Another point I just thought of: it's nice if the full object name is easily predictable as one has to deal with such names when debugging with gdb.

[rgrinberg]

Agreed for not using the closed list of modules. Though using the project name feels a bit odd. In particular, as we discussed recently in another PR it's possible that we'll allow project names to not be unique at some point.

Indeed, but otherwise I'm not really sure what's a good name for alias modules which are shared between executables. Note that the project name is mainly added for debugging rather than uniqueness.

[ghost]

I suppose we could just use Bin__prefix__, just as for libraries.

Are you thinking of gdb debugging BTW? i.e. that including the project name will help determine what executable we are talking about when debugging with gdb?

[rgrinberg]

Are you thinking of gdb debugging BTW? i.e. that including the project name will help determine what executable we are talking about when debugging with gdb?

Yup. Otherwise, all alias modules for executables are going to look quite generic.

[ghost]

Is that an issue though? You can't have two such sets in a gdb session.

[rgrinberg]

I suppose that's true. I'll get rid of it if you prefer that.

[ghost]

I prefer that, yeah. Let's keep things as simple as possible unless we really need the complexity.

[ghost]

Looks good. We do need a changelog entry though

[rgrinberg]

Simplifying the name mangling reveals a new problem:

When we have multiple executables in one directory, we attempt to generate the alias file twice. Wondering how to best address this. A couple of simple options:

• Memoize the function which generates the rule for the alias file
• Generate the alias source in the object directory

[rgrinberg]

I've renamed the option to wrapped_executables. I don't believe that we're using abbreviations in the project file currently. Might as well not start now.

[ghost]

What about generating the alias file in the object directory?

[rgrinberg]

What about generating the alias file in the object directory?

I ended up doing that. But I'm not really liking this solution as we end up generating the same source multiple times. I think it would be better if simply memoized the generation rules.

A couple of other minor fixed I did:

• The alias module is unnecessary for executables with only a single module.
• .merlin files are now correctly generated for mangled executables

And I've also enabled this mode in dune itself. Let's make sure it doesn't introduce any problems in our workflow before releasing to the public.

[ghost]

Why do we generate the same source multiple times? Is it in the case where we have several executable stanzas in the same dune file?

And I've also enabled this mode in dune itself. Let's make sure it doesn't introduce any problems in our workflow before releasing to the public.

That's a good idea!

[rgrinberg]

Why do we generate the same source multiple times? Is it in the case where we have several executable stanzas in the same dune file?

Yup

[ghost]

But aren't the sources different in such case?

[rgrinberg]

But aren't the sources different in such case?

Hmm, good question. I recall considering this before. IIRC, I wanted to generate a single alias module as it would be quite annoying to need the top closure of every executable before generating the alias module. For some reason I thought that it shoudld still be possible to link in an alias module if we don't have an implementation for every module it references. This seems to work I think

[ghost]

Yep, that works fine. What we want is to have a single alias module per executable or executables stanza. However, we don't want to share the alias module between different stanzas as that seems like unnecessary complication for minimal gain.