Le mercredi 1 juin 2016, 14:29:45 David Allsopp a écrit :
> Anil Madhavapeddy wrote:
> > > On 31 May 2016, at 14:36, Louis Gesbert <louis.gesb...@ocamlpro.com>
> >
> > wrote:
> <snip>
>
> > > The issue with `make lib-ext` may be that `opam-admin.top` can't find
> > > the proper opam libraries installed. The Makefile in `admin-scripts/`
> > > has a quick hack to build bytecode versions, but that reiles on
> > > `ocamlfind` to locate the installed versions of the dependencies; it
> > > wouldn't be difficult to improve it to work with `lib-ext` though.
> >
> > It would be very useful if they could work with lib-ext and the toplevel
> > be built by default. Right now there is some oddness where the extlib
> > interactive installer is run if I build `opam-admin.top` manually, so I
> > gave up around there.
>
> lib-ext isn't very well-conceived/constructed, IMNRHO! See
> https://github.com/dra27/opam/commit/f740058a639306c093de3b4f7425a01747239e
> 97. Part of my reason for spending time last year implementing lib-pkg in
> the build system ...
Nice fix, I'd gladly merge the PR
For lib-ext... well, we needed a build system:
- for OCaml
- with no dependencies
and it's just to bootstrap. Yes obviously, lib-ext is an ugly hack, and I am
not proud of it; the doc+Makefiles makes sure you only use it for building the
opam binary and not for usable libraries though
The previous solution was cleaner, but relied on ocp-build. Migrating to
OCamlMakefile was a painful experience, but I can't see a better option
around. Also, it manages to not be too much trouble to maintain.
It could actually make sense to have a real bootstrap and use a local opam
repo; but this has big downsides as well.
> I then hacked admin-scripts/compilers-to-packages.ml and changed the
> #directory entries to include src/{core,repository,format,tools} and
> src_ext and can run that script which I used to replicate the next branch
> on opam-repository and so rebased to create
> https://github.com/dra27/opam-repository/tree/next-windows (I've been doing
> a lot of work locally, which is why it's lagging behind master at the
> moment).
Yes, not very friendly, but that's how I do that kind of thing at the moment
> > > Now, for scripts that get generally useful and somewhat stable, it's
> > > perfectly fine to migrate them to be part of opam-admin. Moving the
> > > scripts to their own repo would also be fine if they reach a critical
> >
> > weight.
> >
> > > Should we improve compat of the Makefile and/or move the 1.2->2.0
> > > functionality to opam-admin ?
> >
> > For the purposes of container-based testing, it would be great if we could
> > move the essential functionality into `opam admin` directly. This will
> > let me insert in the right `git clone / opam admin upgrade` runs into the
> > CI scripts so that OPAM 2 is easy to test for end users.
>
> compilers-to-packages.ml will be a one-time thing, though, surely? Once OPAM
> 2 goes live, surely the main repository will need to work in reverse,
> back-porting an OPAM 1.x.y repository?
Yes, at some point will have to switch the version of submissions to opam-
repository.
_______________________________________________
opam-devel mailing list
opam-devel@lists.ocaml.org
http://lists.ocaml.org/listinfo/opam-devel
