Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Substitute Install Paths? #1253

Closed
japendergrass opened this issue Sep 11, 2018 · 7 comments
Closed

Substitute Install Paths? #1253

japendergrass opened this issue Sep 11, 2018 · 7 comments

Comments

@japendergrass
Copy link

Is there a mechanism to substitute install paths (e.g., $prefix) into a generated file during build?

I expected to be able to accomplish this using a rule with like

(rule 
     ((targets (project.conf))
       (deps    (project.conf.in))
       (action (run sed -e /\${prefix}/%{prefix}/g %{deps} > %{target})))

But %{prefix} (or bindir, libdir, etc) is not listed as a substituted variable in the documentation.

@ghost
Copy link

ghost commented Sep 12, 2018

Not currently, dune doesn't know the value of these parameters. Related ticket: #1185

@ghost
Copy link

ghost commented Sep 12, 2018

And this one as well: #680

@rgrinberg
Copy link
Member

Well $ dune install works without rebuilding the artifacts. To substitute installation directories, we'd need to configure these variables and then run the build. This would be a fairly significant change to dune, do you have some motivation for why you'd like this variables to be substitutable?

@kit-ty-kate
Copy link
Member

I stubbled upon the same issue about a lack of %{prefix} (or similar) variables in mirage/mirage-solo5#61 which currently uses opam config var lib when compiling the package to know where a required directory (which is not a library) is.

@ghost
Copy link

ghost commented Jun 12, 2020

@kit-ty-kate looking at the mirage-solo PR makes me wonder: shouldn't it be opam's job to extend the PKG_CONFIG_PATH variable?

Regarding the original question, during the build we don't know the installation prefix, so we'd need to introduce a configure step to make that possible, which as @rgrinberg pointed out is a significant change. Perhaps we should add that one day though.

On a related note, @bobot is working on a general solution to the problem of data needed at runtime: #3104. That seems worse looking at.

@ejgallego
Copy link
Collaborator

@bobot can we close this?

@rgrinberg
Copy link
Member

I think we can. @bobot can re-open if he disagrees.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants