> On 1 Jun 2016, at 15:29, David Allsopp <[email protected]> wrote: > > Anil Madhavapeddy wrote: >>> On 31 May 2016, at 14:36, Louis Gesbert <[email protected]> >> 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/f740058a639306c093de3b4f7425a01747239e97. > Part of my reason for spending time last year implementing lib-pkg in the > build system ... > > 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).
This does sound like the right approach indeed! > >>> 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 but the functionality still needs to be in opam-admin for other local repositories to be upgraded by their admins. For instance, we maintain several remotes internally at Docker with pinned versions that we use for reproducible binary builds, and those would need to be upgraded when we migrate to OPAM2. Anil _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
