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

problem with OCAMLFIND_DESTDIR and OCAMLPATH #164

Closed
sweeks opened this issue Sep 18, 2012 · 6 comments
Closed

problem with OCAMLFIND_DESTDIR and OCAMLPATH #164

sweeks opened this issue Sep 18, 2012 · 6 comments

Comments

@sweeks
Copy link

sweeks commented Sep 18, 2012

If I have OCAMLFIND_DESTDIR and OCAMLPATH set in my environment, then
opam install res fails with the complaint below:

[ERROR] while installing res.3.2.0
= [RUN] "make install"
...
. Installing library with ocamlfind
. ocamlfind install  res META res.mli strat.mli pres_intf.mli nopres_intf.mli strat.cmi pres_intf.cmi nopres_intf.cmi weak_intf.cmi res.cmi res.cma res.cmxa res.a
. make[1]: Leaving directory `/mnt/local/janevg-data/sweeks/dot-opam/jane-elisp/build/res.3.2.0/lib'
* ocamlfind: Bad configuration: Cannot mkdir /home/sweeks/lib/ocaml-site-lib/res because a path component does not exist or is not a directory
* make[1]: *** [libinstall] Error 2
* make: *** [install] Error 2
  'opam install res' failed

I did run eval $(opam config -env), but I see that isn't setting (or
clearing) those variables.

@avsm
Copy link
Member

avsm commented Sep 18, 2012

Fixing this comprehensively either requires enumerating all the environment variables which might affect compilation (there are a lot) and overriding them, or by not inheriting any of the parent shell variables and specifically setting them in any OPAM-invoked shells.

The latter is somewhat more preferable in terms of deterministic output, but would need some support for the user to override some env variables (e.g. to support http://caml.inria.fr/mantis/view.php?id=5723 )

@sweeks
Copy link
Author

sweeks commented Sep 18, 2012

Not inheriting parent shell variables sounds good.

I'm probably being naive, but I don't understand why that would
require changes to the OCaml tools (issue 5723). There is currently
some set of environment variables that are allowing me right now to
build the packages I am using. It seems to me that setting just that
set is sufficient, without any changes to OCaml tools.

@avsm
Copy link
Member

avsm commented Sep 18, 2012

Right, mandating a specific set of environment variables would be
fine, but it might be too limiting. Sometimes the user wants to
specify an extra variable to be sett (e.g., to globally activate
-g or -p in all pkgs). You can't do this with the current ocaml tools,
but the Mantis issue I linked proposes an env variable that ocamlc
picks up instead of laboriously going through all the Makefiles.

Although, it occurs to me that you can also already do this via compiler
spec files (which can include extra variables for that particular switch).
So it may be sufficient to simply not inherit environment variables.

-anil

On 17 Sep 2012, at 20:31, Stephen Weeks notifications@github.com wrote:

Not inheriting parent shell variables sounds good.

I'm probably being naive, but I don't understand why that would
require changes to the OCaml tools (issue 5723). There is currently
some set of environment variables that are allowing me right now to
build the packages I am using. It seems to me that setting just that
set is sufficient, without any changes to OCaml tools.


Reply to this email directly or view it on GitHub.

@samoht
Copy link
Member

samoht commented Sep 18, 2012

You seem not to be the first one to hit this issue, so I guess we should do something about it. Maybe starting from a fresh environment is the right way to go. And yes, for the compiler env variables, the right way to define them is in the compiler description files.

@samoht
Copy link
Member

samoht commented Oct 3, 2012

This should be fixed in 0.7. OPAM now displays a warning if the wrong environment variables are set.

@xavierleroy
Copy link

xavierleroy commented Mar 9, 2023

The recently-reported issue ocaml/Zarith#136 might be an instance of this old problem. I'll let you decide. [ Edit: fixed the URL ].

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

No branches or pull requests

4 participants