> Biggest feedback at the moment is that compilers-as-a-package is a fabulous > innovation – I had originally expected to need to add lots of horrid > Windows (and OCaml, therefore)-specific stuff to the OPAM program, but in > fact all I've had to do is add generic features to OPAM and then handle the > rest in the package itself, which is great!
That's good to hear :) > > The "target-filename" part being optional. See for example > > http://opam.ocaml.org/2.0~dev/packages/ocaml/ocaml.4.01.0+BER/opam > > Ta, I came across it subsequently too! I've extended it (or rather, will > shortly extend it), to allow it to refer to the URL of another package, as > the ocaml package needs to pick up the sources of the flexdll package > installed just before it in order to bootstrap correctly. Hm, that seems a bit ad-hoc and introduces metadata dependencies of a new kind. What if flexdll has a git url or is pinned locally ? > I've gone with the command line options for now (with an error check to > ensure that they're only given when installing a switch). At the moment, > they define three global variables switch-cc, switch-libc and switch-arch > which are only available during the switch installation, so if they want to > be kept, the compiler package has to capture them in its own .config file. > ocaml.system remains a horrible hack under this mechanism (the script > identifies that it's in a switch named "system" and uses that fact to probe > switch-cc, switch-libc, and switch-arch...) That would likely break `opam switch foo --alias-of system`. Adding `--set- variables <bindings>` to `opam switch install` would be a good first step, and if we find suitable sugar later on we may add it. > It's not particularly pretty, but it does seem to work in the absence of > something more general for now. In particular, I've restructured the base > packages and added a package called compiler whose purpose is to store > variables (in particular, compiler:o, compiler:so and compiler:a giving > important file extensions for object files, etc., which are necessary for > writing generic package specifications). The only bug I had to fix with > that so far is to thread the config files correctly through parallel_apply > (before they were only re-loaded at the end of the installation), but there > is a comment in the code that you already aware of problems there! hm, forgot about that TBH, I'll need to check :) > > Yes, just philosophical, there is no constraint here besides the > > arbitrary > > "I don't want to recompile the compiler, ever". > > > I've spent the last couple of days working through this, and I think it's > definitely worth relaxing that restriction. I've altered opam switch so > that only the root package is the compiler package – so only ocaml.version > is in the compiler section of switch-state. Have a look at this > transcript: > [snip] > > That seems a potentially very useful thing to be able to do – and you don't > lose the safety of the "compiler" packages – opam remove flexdll (or > base-unix, etc.) will still complain that this would involve removing the > compiler: > [opam:4.02.0] [git:windows] C:\DRA\opam\src>opam remove flexdll > Your request can't be satisfied: > - Package ocaml is part of the base for this compiler and can't be > changed > No solution found, exiting Note, though that even with the current system, the restriction that compiler packages are immutable is somewhat lifted if you pin the package: so the above should work without changes (I haven't tested pinning one package of the "compiler packages" set and recompiling its compiler dependents though) _______________________________________________ opam-devel mailing list opam-devel@lists.ocaml.org http://lists.ocaml.org/listinfo/opam-devel
