On Thu, Jan 17, 2002 at 02:02:36PM +0100, Judica�l Courant wrote: > le jeu 17-01-2002 � 11:47, Sven a �crit : > > > > Mmm, i suppose you are speaking abou8t coq, isn't it ? > > > Right. Although other packages can be concerned too... > > > The correct way to handle this is arch depending build deps. > > > > Currently, ocaml.opt (or whatever its name is) is built on arm, alpha, i386, > > powerpc and sparc. (ia64 has a bug, but should be added to it). > > > > I don't know exactly how it works, but my understanding is that it is possible > > to have coq depend on ocaml.opt on some arches and on ocaml on all the others > > (well maybe on ocaml.opt and ocaml in the supported arches case). > > > > > Maybe a fix would be to provide a "fake" ocaml-native-compilers for > > > architecture that do not support ocaml-native-compilers? > > > > Mmm, i would prefer not, but then we have to look into this a bit more and see > > what is the best solution. > > > > I think however this "fake" package mechanism would be interesting for > several reasons:
Mmm, will consider it ... > 1) no need for other package maintainers to deal with > architecture-dependent stuff. As you told: you do not know how > arch-dependent build-depends work, I do not either and probably few > maintainers know. That something is possible does not mean that every > maintainer can (and will) do it. Ok,first argument is the lazyness of debian packagers. > 2) packages build-depending on caml will always use the best available > compiler. Arch-dependent things evolve with time ; if package maintainer > deal with them, they will have more work. If say 68000 is supported by > ocamlopt tomorrow, you first will need some time to add it to Err, not ever probable, there was a m68k native code compiler back then, but it was dropped as the ocaml team dfon't have a m68k machine anymore. > ocaml-native-compilers, but also I will have to take some time to make a > new release of my package if my package is arch-dependent. People will > benefit on this new arch only when both have been done. By contrast, if > my package is arch-independent, they will benefit from the new arch as > soon as it is added to ocaml-native-compilers. Mmm, maybe a conditional build depend would be nice. > 3) this will be less work for you: make ocaml-native-compilers available > on any platform. Just do an "make opt.opt || true". Then if the arch is > not supported, the package will just contain no binary. This way, you do > not even need to know precisely which arch are supported: when there is > a new upstream release, just make it available, if a new arch is > supported, the binary will be available to the user. No, it will be more work for me. The current implementation is easier. > On the other hand, I see two potential problems with this > 1) make opt.opt might fail on a supposedly supported arch. If you > silently ignore the error, you will not detect the problem immediately. \ YEs, like the ia64 case right now. > 2) one might make a package that really relies on the fact that you have > the native compilers. Mmm, ... > As for 1) a solution could be to replace "make opt.opt || true" by > something more subtle like > > SUPPORTED=no; \ > for a in arm alpha i386 powerpc sparc ; \ > do if [ $(ARCH) = $$a ] ; then SUPPORTED=yes ; fi ; \ > done; \ > make opt.opt || [ $$SUPPORTED = no ] > > this way your build fails if make opt.opt fails on a supposedly > supported arch. > > As for 2) maybe you could release two packages: ocaml-native-compilers, > available only on arch that support opt.opt and > ocaml-native-compilers-or-nothing, arch-independent, fake on > non-supported arch (maybe we should find a more appealing name :-). Too complicated ... Anyway, i guess there will, in the forseable future, only be coq with such problems, and anyway, most probably therte will be a new release of coq when there is a new release of ocaml wityh new arches. Friendly, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
