Document that executables using dune-configurator depend on config file - #11964
Open
shym wants to merge 1 commit into
Open
Document that executables using dune-configurator depend on config file#11964shym wants to merge 1 commit into
dune-configurator depend on config file#11964shym wants to merge 1 commit into
Conversation
…file In the documentation, indicate in the example of a program using `dune-configurator` that it depends on the configuration file it will read so that dune will know it must run the program again if and when the configuration changes Signed-off-by: Samuel Hym <samuel@tarides.com>
Member
|
I would prefer not to point users at using this internal path. It has changed over the years and it might again. How about we introduce a special action that runs a configurator binary and introduces a dependency on this file? Or, we add a new type of dependency to the specification in |
Contributor
Author
Indeed it felt dangerous territory to depend on something in
That would be a nice solution! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR proposes to document in the example of a program using
dune-configuratorthat it depends on the configuration file it will read so that dune will know it must run the program again if and when the configuration changes. The proposed approach uses a glob to make it a bit more robust to changes (of file names or paths anddune-configuratorversions).The corresponding issue, namely a case in which the program should be run again and wasn’t, came up with the mirage-crypto project which uses
dune-configuratorto detect some C flags that are specific to the target architecture: a change of the target architecture fromx86_64toarm64didn’t trigger a re-run of the configure program; then the build failed when trying to passx86_64-specific flags to thearm64gcc compiler.The explicit dependency suggested by this PR fixes that issue. The question that arose in the mirage-crypto PR is whether that’s the proper way to express that dependency, as it is referring to files that are created implicitly by dune. What do you think about that?