stublibs and bytecode only packages. Was: Re: Plans [Re: Cameleon 1.0]
On Wed, Aug 28, 2002 at 11:19:59AM +0200, Jérôme Marant wrote:
> On Wed, Aug 28, 2002 at 11:05:07AM +0200, Stefano Zacchiroli wrote:
> > On Wed, Aug 28, 2002 at 10:35:11AM +0200, J?r?me Marant wrote:
> > > I'm afraid, I don't have any web access right now. But I'll try to use
> > > my memory:
> >
> > Ok, no problem, I googled a bit and I found out the complete index:
> ...
> > Really Impressive!!!
>
> The least that can be said ;-)
>
> > That said, I propose to package each library in a single package, this
> > seems to include: options (liboptions-ocaml{,-dev), okey
> > (libokey-ocaml{,-dev}), configwin (libconfigwin-ocaml{,-dev}), gpattern
> > (libgpattern, ocaml{,-dev}) and I will include also ioxml[1] (what about
> > the package name?)
>
> Most of the libs do not provide shared versions. I think it is fine
> because they are rather small
Mmm, remember that adding dynamic loading stublibs also has the
advantage of making the resulting bytecode program arch: all, that is
the exact same binary can run on all arches, so i would suggest to build
dynamic loading stublibs anytime it is possible, and separate them in
their own package.
This is not really important right now, but in a later time, we may
build a separate bytecode package and provide the native code only for
arches that support it. This would create less load for the
autobuilders on arches like: mips, mipsel, m68k and hppa at least. I
think especially the m68k guys would be happy with this.
The scheme would be to do something similar to what was done with the
autobuilders, with a diversion or something such. It needs more
reflexion and discussion about it. But then, maybe now is the time for
it, what do you all think ?
Friendly,
Sven Luther
Reply to: