Skip to content

Idea/Proposal: Allow for public libraries to depend on private libraries #1017

@rgrinberg

Description

@rgrinberg

Abstract

Currently, private libs may depend on public libs but the reverse isn't allowed. Note that an analogous situation exists with executables, but this restriction is absent. This proposal seeks to harmonize the situation between public libs and public exes. Both should be allowed to consume private libs as dependencies.

Issues to address

To solve this problem, three issues must be addressed:

  • Private libs should work the same way as public libs. Regardless of whether they are consumed from findlib or from a local workspace, the handling of deps should be the same.

  • Private libraries should be hidden from users of the public libs

  • There should be a guarantee that public libs do not leak the types of private libraries in their interface.

Proposed solution

tl;dr is we'll install the private libs alongside the public libs in findlib and differentiate the two with a naming convention. Private libs will be guarded from downstream users by hiding the cmi's. To guard private types escaping into public interfaces, we won't allow the user to compile the public interfaces against the private lib's cmi's.

The first issue is really an issue when the public libs (with private deps) are installed as findlib libs. The private libs must also be installed alongside. This can be accomplished with some naming convention for private libs. Note that we cannot just "inline" the object files of a private lib with the public lib because multiple public libs can share the same private libs. I understand this is a huge hack, though hopefully real namespaces would allow for a simpler solution.

The second issue is also resolved by not installing the .cmi's of the private libs. This is the same mechanism that we'll use for implementing private modules.

The last issue is resolved by making sure that the interfaces of public libs will not be compiled against the interfaces of private libs. Hence, we'll exclude paths of the .cmi's of private deps when building the .cmi's of the public libs. This should make sure that no types defined in a private lib can end up in the interface of a public lib.

Possible issues

There's a bit of a complication with private modules. Private modules should really be able to export the types of private libraries.

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedaccepted proposalsproposalRFC's that are awaiting discussion to be accepted or rejected

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions