Skip to content

Conversation

@maiste
Copy link
Collaborator

@maiste maiste commented Jul 3, 2025

This PR is the first of a set of four PRs related to the introduction of Parameterized Libraries in Dune.

This feature is only available with OxCaml until it is upstream to the compiler.

It contains multiples changes:

  • Support for the library_parameter stanza
  • Test of the newly introduced stanza. The tests will be updated with the next PRs.
  • The documentation related to the new stanza.

Closes #12084

@maiste maiste added the oxcaml Related to the support to OxCaml functionnalities label Jul 3, 2025
@maiste maiste requested review from art-w and rgrinberg July 3, 2025 15:04
@maiste maiste marked this pull request as ready for review July 4, 2025 08:14
Specifies what modules are part of the library parameter. By default, Dune will use
all the ``.mli`` files in the same directory as the ``dune`` file. This
includes ones present in the file system as well as ones generated by user
rules. You can restrict this list by using a ``(modules <modules>)`` field.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A library parameter can only have a single .mli file, so the documentation should not say "all the .mli files in the directory"... In fact I'm not sure if we should keep the (modules ...) field, since its value should always be parameter_name

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we go in the direction where we keep the modules field or if, by default, library_parameter only take the parameter-name and exclude the rest of the modules? My point of view is that modules would keep Dune users in familiar waters but taking parameter-name would remove the risk to specify multiple modules... I'm not sure about the best behaviour to adapt here.

In the rework version, I have simplified the phrasing for our need.

WDYT @rgrinberg?

@maiste maiste force-pushed the library_parameter branch from 1af67e8 to 6890386 Compare July 4, 2025 14:09
@maiste maiste requested a review from art-w July 4, 2025 14:10
@maiste maiste force-pushed the library_parameter branch 2 times, most recently from 423c46b to ac62dfa Compare July 8, 2025 09:29
@rgrinberg
Copy link
Member

@maiste is this ready for another round of review?

@maiste
Copy link
Collaborator Author

maiste commented Jul 8, 2025

Yes it is 😄 I have addressed all of @art-w comments.
Thanks!

@maiste maiste force-pushed the library_parameter branch from ac62dfa to 0dd1910 Compare July 22, 2025 09:37
@maiste
Copy link
Collaborator Author

maiste commented Jul 22, 2025

@rgrinberg gentle ping. I have rebased the PR with main to make the CI happy. I'll rework the commit history after review to make more readable commits.

Copy link
Member

@rgrinberg rgrinberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I think the library_parameter stanza is overly permissive at the moment. Might be worth documenting this in the tests.

@maiste
Copy link
Collaborator Author

maiste commented Jul 28, 2025

Thanks for the review @rgrinberg! Just to understand before pushing new tests, what do you think in the stanza is overly permissive? Is the fields we kept that should have a default value instead (like optional)? Or is it something else?

and+ package = field_o "package" (located Stanza_common.Pkg.decode)
and+ enabled_if = Enabled_if.decode ~allowed_vars:Any ~since:None ()
and+ synopsis = field_o "synopsis" string
and+ stdlib =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this field makes sense for library parameters

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if you want to use Base as the standard library? Otherwise, I can remove it.

Copy link
Member

@rgrinberg rgrinberg Jul 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't work for base because it's a regular library. This is a field that is only useful for the stdlib itself. In other words, it's for using dune to build OCaml itself (for a better development workflow)

@rgrinberg
Copy link
Member

Sorry my previous comment was a bit opaque. I expanded on the fields I think are unnecessary and which tests I would like to see.

@maiste maiste force-pushed the library_parameter branch from 48a2416 to fb81e0f Compare July 28, 2025 15:45
@maiste
Copy link
Collaborator Author

maiste commented Jul 28, 2025

Thanks for the clarifications! I have rewritten the git history to make it cleaner (to use merge commit when merging the PR). I have pushed a test to check the result when using a module. As you said it is currently too permissive as we don't check for the module size. We have extra tests we backported from JS tests but that are paired with implementation, instantiation and parameterization. With @art-w, we intended to push them later along with the paired code.

@maiste
Copy link
Collaborator Author

maiste commented Jul 29, 2025

@Alizter @rgrinberg I have made the changes according to your feedback. If this version is good, I will rework the git history to have something cleaner (working with the DCO check) and merge it.

Small question: even if this is experimental, should I add a CHANGES.md entry?

@rgrinberg
Copy link
Member

If you think it's useful for users to know about this addition, you're welcome to add it.

@maiste maiste force-pushed the library_parameter branch 2 times, most recently from e13fcdc to 751c4fd Compare July 30, 2025 09:50
@maiste
Copy link
Collaborator Author

maiste commented Jul 30, 2025

I have pushed a CHANGES.md with the experimental label to make it clearer it is not something stable yet. I have also rewritten the history. @art-w and @rgrinberg if this is good in the current state for you, I'll merge the PR.

@maiste maiste added this to the 3.21 milestone Jul 30, 2025
@maiste maiste force-pushed the library_parameter branch from 751c4fd to e237f70 Compare July 31, 2025 12:08
@rgrinberg
Copy link
Member

It looks to be in a good state for me.

Co-authored-by: Rudi Grinberg <[email protected]>
Co-authored-by: ArthurW <[email protected]>

Signed-off-by: Etienne Marais <[email protected]>
maiste and others added 6 commits July 31, 2025 14:21
It uses the (use oxcaml 1.0) extension to make sure the experimental
feature is not exposed directly to Dune users.

Signed-off-by: Etienne Marais <[email protected]>
This commit adds a first batch of tests regarding the parametrized
library. These tests are extended in future commits to add more checks
as it requires extra behaviour to check it deeper.

Signed-off-by: Etienne Marais <[email protected]>
Signed-off-by: Etienne Marais <[email protected]>
Signed-off-by: Etienne Marais <[email protected]>
@maiste maiste force-pushed the library_parameter branch from e237f70 to e45b5fa Compare July 31, 2025 12:21
@maiste maiste merged commit cdca0db into ocaml:main Jul 31, 2025
26 checks passed
@maiste maiste deleted the library_parameter branch July 31, 2025 12:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

oxcaml Related to the support to OxCaml functionnalities

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[OxCaml] Parameterized libraries: library parameter

4 participants