On Wed, Feb 20, 2008 at 06:43:27PM +1100, Peter Hawkins wrote: > Hi... > > On Feb 20, 2008 9:50 AM, Paul Bone <[EMAIL PROTECTED]> wrote: > > Mercury also supports 'grades', this makes it different to other > > compliers and more interesting to package. Each grade represents a > > complier backend and some options. There are two C backends, a Java > > backend, and Erlang backend and a MSIL backend. Options can include > > optional garbage collection (as apposed to never reclaiming memory), > > profiling support, debugging support and more. > > > > I'd like to package the library and runtime for each grade. These can > > all be installed concurrently and won't conflict. > > There are at least two issues you may have to deal with here: > * Mercury does not provide any guarantees about a stable library ABI, > so you'll have difficulty packaging grades using shared libraries and > not breaking applications when you update the libraries.
Hrm, that's true. I know that at the top of each .m file in the standard library a comment describes the stability of the API exported by the library. I've also never seen any avalible call change, or go away. Some more interesting grades such as deep profiling change and can no-longer be linked with previous version of the same grade, dispite there being no mercury library code changes, only changes in the complier that will generate incompatible C code. (I'm currently working on such a change for the deep profilier). The real solution would be to standardize the API, and version the runtime along with libraries and programs compiled against it, which is a problem for upstream. Other solutions are static linking or placing the stable version number in the package name, (like zlib1g). Then programs may depend on the version they where compiled/developed against. This could get messy but since releases are sledom it may be ok. > * Mercury standard libraries can be very large (tens of megabytes in > some of the debug grades), so packaging every possible grade seems > rather wasteful of archive space. If you ask me, you need to pick a > small set of useful grades which cover most use cases. I'm not sure > how many architectures Debain supports at the moment, but if you > aren't careful you could easily consume hundreds of megabytes of > fileserver space just on Mercury library grades (10+ architectures * > 10s of Mb/grade * many grades). I begun listing the grades I think would be useful to package, I found about 6 grades, so that's not too bad. I'll list them properly when I build the package and check that I havn't forgotten any. We can also reduce space by limiting the architectures that this is avalible for, (If that's cool with Debian). I don't expect there to be much interest in arm, mips, mipsel or m68k. That said, I want mipsel packages for myself for another project :-) Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
