Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for OCAMLTOP_INCLUDE_PATH environment variable #1841
The rationale is not explicit in the MPR ("(I can provide full details if one needs to be convinced).").
I don't need the full details, but currently, the toplevel and compiler share the same external interface for setting the include path; is there a good reason to break it? Assuming the proposal is useful for the toplevel, isn't it harmless for the compiler as well?
I don't understand enough of the use case for the proposal, but wouldn't OCAMLTOP_INCLUDE_PATH be set by some tools (opam?) as well?
Anyway, since the feature is already available, and if it turns out to be useful enough to deserve some additions: what about declaring that OCAMLPARAMS is supposed to be used by end users?
One downside of the current design of
The full details are no explicit... As I said there the rationale is that it's difficult for
The reason is that on a bare
The compilers don't need to
(That doesn't mean that we could also add an
Yes it would be setup or extended by opam switches.
Ok I still prefer when @alainfrisch is convinced. So if that can help I'll tell the whole long and boring story (@samoht and @AltGr apologies for the fiction). Even if he doesn't read it it will document the crap that we have now in the
Let's start with the beginning (and root of the problem ;-)). The OCaml system essentially leaves the business of managing and loading libraries to an external mechanism -- sure there's
This means that ocaml scripts (
This is all nice and clean: it makes you scripts relocatable, and you can add the directive to your
Now one day, @samoht and a few other people are bored and design
@samoht being resource minded, he allows for a switch to have the OCaml installation live outside of the switch for it to be provided by your regular operating system; a so called system switch. For many reasons it is however better not to let
So when you install
So @samoht designs this solution: we are going to install these top init files in a dedicated directory in the
Since he finds no way to runtime configure the
and adds the variable to your environment with the right directory on
A few years later @dbuenzli is a bit fed up with shell scripting and the distribution of his packages and writes
The system is kind of a hack but seems to work reasonably well. However soon enough people start complaining that
Since @dbuenzli is a bit impatient with the situation and kind of a dirty man he seeks for the minimal solution working immediately. Blinded by his anger he introduces a terrible solution: the wrapper.
He tweaks the
Problem solved and advertised as such. @dbuenzli is so happy and it works so well for everyone that he cowardly shies away from solving the actual problem correctly.
Now @AltGr hears about this being solved at the same time he's busy designing opam v2. Being a tasteful person and somehow falsy trusting me and @samoht not to be pigs he rightly doubts the beauty of the
A few days ago @dbuenzli introduces new software that also needs to boostrap via a file installed in
However he suddenly learns that
He can still
At that point deep guilt start to stream in as he realizes that the right way of getting rid of all of these hacks is to go back to @samoht's forgotten desire and provide runtime configuration of
He is personnaly quite sure that this configuration should not happen via