Re: splitting ocaml-native-compilers
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,
Reply to: