Le mardi, 13 octobre 2015 à 02:54, Louis Gesbert a écrit : > I'm not very familiar with cross-compilation, and this has the huge merit of > being easy to understand -- hence to handle, I guess.
Neither do I except in the past with systems that handle all the crap for you transparently like xcode and recently with my bare metal experiments [1]. The goal is to try to align the build tools and opam so that in the end library makers and packagers don't have to think much to have their cross lunch. Especially if they are not fundamentally interested in it while their users may be. In particular we don't want to have to maintain separate opam-repositories, like opam-android has to, to enable cross-compilation since this can't possibly scale. > I have some remarks on the installability checks: recursively trying to solve > the cross-arch package dependencies would be a bad idea, and what you propose > > wouldn't scale well to upgrades, removals, etc. -- thankfully, the solver > should be able to do the work for us yet again. I was suspecting that, I'm glad you have a solution to the problem. > This wouldn't impact the `arch-specific:` field (which _could_ also make the > package unavailable in case none of its specific arches is present on the > switch, to avoid confusion ?). Why not. I'm still a little bit dubious about this part of the proposal: fundamentally the person making such a package could simply declare it available on all architecture and concretely do a nop in its install instructions on the non `arch-specific:` architectures. My concern here was about meta-data information loss: such a package would look like installable on each architecture but it is architecture specific, a fact that we would no longer see in the package metadata. I think we could do without this if it simplifies things but metadata information would be lost. > I also have a question on build order: is it specified across archs ? I would say no so that we can parallelize the build as much as possible. Concretely we assume that architectures live in isolation possibly only being able to see the build architecture for technical build reasons. > Should only `build` always be first ? Yes `build` should be first (I updated the doc to make that clear), so that a package can possibly refer to its counter part or those of its dependencies in the build architecture — but I'd say that a package with a good build system which is able to distinguish his build and host products and whose dependencies share that property should not need to be able to do that. > Also, we could probably make it so that `xbin` is an alias for `bin` in the > case of the build arch, so that the change is invisible when not doing cross- > compilation. Yes. > I don't otherwise see any big difficulties for implementing this in opam! Cool. Having that could open up quite a few nice opportunities. Best, Daniel [1] http://erratique.ch/software/rpi-boot-ocaml _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
