[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: splitting ocaml-native-compilers



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:

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.

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
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.

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.


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.
2) one might make a package that really relies on the fact that you have
the native compilers.

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 :-).

Judicaël.
-- 
Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/
(+33) (0)1 69 15 64 85
"Heureux ceux qui savent rire d'eux-mêmes :
 ils n'ont pas fini de s'amuser !"



Reply to: