Towards a bridge with ocamlfind

[samoht]

This series of patches completely removes the support for custom compilation options which were in OPAM since its beginning. This feature was complex and useless, and I'm sure nobody will miss it. Now we have a clean and clear semantics: every package can defined a <pkg>.config file at this root, with global variables which can be read by other packages if necessary.

We can now use the library and syntax field which were here from the beginning, and start filling them with interesting findlib metadata. I've push an example of automatic extraction to opam-repository soon.

[dbuenzli]

I think this fits very well with the declarative approach of topkg where instead of generating build systems, the build system always knows how to build everything but the package builder makes selective calls in the build system according to the environment. This feature will allow to easily enrich build environments.

I do however have the following comments.

1. It seems that config files are in $SWITCH/config/$PKG.config which AFAIK is not a standard unix directory.
2. The mechanism is divorced from the .install mechanism.

For me it seems that this will make it needlessly harder for supporting regular package system with opam packages. Other package system may not like the fact that things are installed in $PREFIX/config/ and opam-installer will not handle the installation of PKG.config which seems rather silly.

Therefore I would rather suggest that:

1. A standard unix directory be chosen for the installation of $PKG.config. I would suggest either lib (ocamlfind-like) or etc (unix-like). That is opam will look into lib/$PKG/$PKG.config for the variables.
2. Let the package's install procedure install the config file at that location by itself. That is specify the file in the right .install section (lib or etc as choosen in 1.) if you have such a file or let your build system copy the file at the right location if you don't.

[samoht]

Agreed with you Daniel. There's just one slightly annoying point: currently, opam relies a lot on config/global-config.config for global variables. Not sure it's a good idea to move it, I don't know where, and we should handle OPAM upgrade gracefully.

[samoht]

don't merge yet, seems that the opam-admin script is not working properly yet.

[dbuenzli]

Well you can leave that one for opam, it wouldn't be used by other package managers anyway. But the config for packages shouldn't be there.

[samoht]

@dbuenzli so you reckon that opam config var <pkg>:<variable> should read in lib/<pkg>/<variable>.config ?

We could distribute an opam-variable binary to do the same thing than opam-installer to deal with reading configuration variable I guess.

[dbuenzli]

Yes lib/<pkg>/<pkg>.config to be precise and yes having a tool to read that would be nice. Note that maybe rather than multiply the tools we could have a generic opam-pkg tool, that allows to 1) read fields from opam files (extracting metadata) 2) read fields from .install files and handle them as opam-installer does and 3) read fields from .config files.

[dbuenzli]

Or maybe lib/<pkg>/opam.config would be even better, no need to repeat the package name again.

[samoht]

Good to merge now.

btw, with opam itselft you can already do 1)opam show <pkg> -f <field> and 3) opam config var <pkg>:<variable>. There is no easy way atm to read the .install files, which should be quite useful to have I guess.

And yes, providing opam-pkg to help non-opam users is interesting. But not very high on my priority list ...

[dbuenzli]

Sure but opam show is a little bit different as it acts on packages in the repo. You'd want it to act on a concrete opam file (e.g. when you do distributions, though I wouldn't need it with my current workflow).

Regarding opam-pkg, I understand it's not on your priority list. But since I started to use the topkg approach (previously with shell scripts), I was asked more than once why I was not simply (sic) using oasis -- a funny question, the answers being so obvious. So I gently try to push to make sure there's good tooling that supports my approach for system packagers...

[AltGr]

Awesome, thanks !
Did you check it didn't break opamfu / opam2web ?

[samoht]

@AltGr I haven't checked, I think it will break opamfu/opam2web indeed. I'll try to fix that later this week (and move the location of .config files as well).