[opam-devel] OPAM Roadmap -- what next ?

Louis Gesbert louis.gesbert at ocamlpro.com
Fri Dec 26 01:32:40 GMT 2014


Cool!
On the "fake" compiler, with latest OPAM you should be able to switch "preinstalled" to "false", which should avoid some complications (recompilation if system OCaml is changed...) ;
and, still in the ".comp" file, you should be able to add:

env: [ "LD_LIBRARY_PATH" += "%{lib}%" ]

to avoid the manual hack.

Best,
Louis

> - Sebastien Mondet, 22/12/2014 09:51 -
> On Sun, Dec 21, 2014 at 9:02 PM, Louis Gesbert <louis.gesbert at ocamlpro.com>
> wrote:
> >
> > Wow! So non-OCaml OPAM is already a reality ! :) (not counting Coq here,
> > which sits on top of OCaml)
> > One point for "agnosticity" !
> >
> >
> 
> Just noting, I also experimented with non-OCaml opam repos, for C/C++
> crappy software:
> 
> https://github.com/smondet/bfx-opam-repo
> 
> - for exectuables to “see” libraries, I needed the LD_LIBRARY_PATH hack in
> the README
> - to avoid compiling OCaml, I had to create that “fake” compiler
> 
> 
> 
> 
> 
> > > - Ashish Agarwal, 21/12/2014 10:22 -
> > > > Having a way to have multiple versions of the same library installed in
> > > the same switch could be very cool as well
> > >
> > > For websites, I need to pull in various Javascript libraries and CSS
> > > frameworks, which I can copy into my repo manually or manage with
> > something
> > > like Bower. However, I'd rather have everything via opam, so I started a
> > > repo for this [1]. The files of these packages are simply copied at build
> > > time, and thus there's no reason I couldn't have multiple versions of
> > > jquery installed at the same time. (I appreciate this is not a priority
> > use
> > > case.)
> > >
> > > [1] https://github.com/solvuu/opam-repo-web
> > >
> > >
> > >
> > >
> > >
> > > On Sun, Dec 21, 2014 at 8:51 AM, Daniel Bünzli <
> > daniel.buenzli at erratique.ch>
> > > wrote:
> > > >
> > > >
> > > >
> > > > Le dimanche, 21 décembre 2014 à 14:26, Peter Zotov a écrit :
> > > >
> > > > > Through ocamlfind, of course, there's nothing else now.
> > > > >
> > > > > Sure. But note that ocamlfind explicitly refuses to deal with
> > versioning
> > > > > constraints; it's even in the manual. So the dependencies of neither
> > > > > A.1 nor A.2 are not expressible in META.
> > > >
> > > > That's the point, I'm not asking ocamlfind to resolve any versioning
> > > > constraints. It's all based on the name of the package (if . is not
> > allowed
> > > > in the name then substitute by another character). With this packages
> > are
> > > > able to specify a dependency on a particular version.
> > > >
> > > > I don't see that as a long term solution; I hope we can eventually get
> > rid
> > > > of that hideous naming resolution hydra and menagerie of meta files we
> > have
> > > > now (which basically means ocamlfind should go). However I suspect
> > that the
> > > > underlying mecanism (install each package in PKG.VERSION directory)
> > will be
> > > > similar for whatever replaces the current mess, so there's no harm in
> > > > having it now.
> > > >
> > > > Daniel
> > > >
> > > >
> > > > _______________________________________________
> > > > opam-devel mailing list
> > > > opam-devel at lists.ocaml.org
> > > > http://lists.ocaml.org/listinfo/opam-devel
> > > >
> > _______________________________________________
> > opam-devel mailing list
> > opam-devel at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/opam-devel
> >


More information about the opam-devel mailing list