[opam-devel] OPAM 2.0 features

[Louis Gesbert]

Le jeudi 26 mai 2016, 10:36:48 David Allsopp a écrit :
> Hi (Louis mainly, I expect!),
> 
> 	I've rebased work I've been very slowly doing onto the OPAM 2.0
> alpha release and have been starting to get opam switch to work. There are a
> few things which I need to be able to do for this, and I'm wondering if
> there any opinions (or even existing features I've missed) as to
> mechanisms...

Great! All feedback is very welcome at this stage.

> 1. Downloading a package from several tarballs
> 	I've not finished delving into the full details, but I think I'm
> correct that the url file / section can only specify a single archive, even
> if it can be made available by multiple transports? Bootstrapping OCaml on
> Windows requires two tarballs, so I was going to extend the url system to
> allow multiple tarballs to be specified (with control over where in the
> overall tree they are extracted), rather than hackily including the second
> one in files and extracting it using a build command.

Some other compilers, e.g. metaOCaml, have the same requirement, since they 
consist of the official OCaml tarball plus a huge patch, so I have added a way 
to handle this.

The `url` section or file still is a single source, and the commands are 
executed from its root (after extraction if necessary). But there is now also 
an opam field `extra-sources:` that you can use to download more files, 
unextracted, to the build directory. The format is:

    extra-sources: [ [ "URL" { "target-filename" } "MD5" ] ... ]

The "target-filename" part being optional. See for example 
http://opam.ocaml.org/2.0~dev/packages/ocaml/ocaml.4.01.0+BER/opam

> 2. Specifying package variables at opam switch install
> 	I've extended the ocaml package variables to include three new ones:
> ocaml-arch (which is exactly the architecture determined by OCaml's
> configure script), ocaml-cc (which is "cl" for a Microsoft C compiler based
> OCaml or "cc" for the rest of the world), and ocaml-libc (which is "msvc"
> for the four native Windows OCaml ports and "libc" for the rest of the
> world).
> 
> 	At OPAM switch time, one selects which Windows port you get by
> specifying these three variables. So, for example, mingw64 is
> ocaml-arch=amd64, ocaml-cc=cc, ocaml-libc=msvc; msvc32 is ocaml-arch=i386,
> ocaml-cc=cl, ocaml-libc=msvc; cygwin64 is ocaml-arch=amd64, ocaml-cc=cc,
> ocaml-libc=libc.
> 
> 	My question is how to specify these - the concept of "architecture",
> "C compiler type" and "C runtime library" is generic enough that it doesn't
> feel too bad to have opam switch --cc=cl --arch=amd64 4.03.0 and have the
> package initialise ocaml-arch, etc. based on those globally available
> variables. However, is there any plan (or existing feature) for a more
> generic way of specifying package input variables? (discussed in
> https://github.com/ocaml/opam/issues/2247).

a) for the _output_ variables, you can define them in your `PKG.config` 
variable (automatically installed by opam if present in your build dir). Note 
that, at the moment, variables defined by the compiler package get exported as 
global variables (so you can access e.g. `ocaml-version` anywhere), but there 
are limitations due to this and it is likely to disappear from the final 
release (see https://github.com/ocaml/opam/issues/2537 for details). You can 
always access them through `ocaml:VAR` inside the script parts though.

b) nothing yet for _input_ variables, but #2247 is still something I need to 
work on. You can define global variables through `opam config set`, though, so 
an option in the meantime could be to use `opam switch install --empty`, set 
the variables, then install the compiler (the option to install and mark as 
compiler is missing at the moment, though, for that you'll have to edit 
`SWITCH/.opam-switch/switch-state`)

> 3. Upgrading dependent packages for the root
> 	Any Windows OCaml installation will depend upon FlexDLL objects
> compiled with the specific C compiler combination. Although in principle
> these could be shared between multiple switches (the object files vary
> according ocaml-cc, ocaml-libc and ocaml-arch; not ocaml-version), it makes
> sense to compile these two object files per-switch, rather than introduce
> yet another installation layer.
> 
> 	This means that in addition to the base packages, the Windows OCaml
> package depends on a flexdll package. Is there any philosophical reason for
> that not to be part of opam upgrade? Obviously, one doesn't want to be
> trying to upgrade the ocaml package, but why lock its dependencies at a
> given version? It would be quite nice if a new version of flexdll is
> released to be able to have opam upgrade notice that flexdll can be
> upgraded, determine that the root package must therefore be recompiled and
> so automatically recompile the entire switch.
> 
> 	Is it just for philosophical reasons that the dependencies of the
> root package are not considered for upgrade or is there a technical
> consideration?

Yes, just philosophical, there is no constraint here besides the arbitrary "I 
don't want to recompile the compiler, ever".

Hope this helps,
Louis