On Tue, Jul 28, 2009 at 09:30:58AM +0200, Lucas Nussbaum wrote: > On 28/07/09 at 10:58 +1000, Paul Bone wrote: > > On Mon, Jul 27, 2009 at 05:13:06PM +0000, brian m. carlson wrote: > > > On Mon, Jul 27, 2009 at 05:34:44PM +1000, Paul Bone wrote: > > > > * Package name : mercury > > > > Version : 0.13.1-rotd20090725 > > > > Upstream Author : Mercury Group <mercury@csse.unimelb.edu.au> > > > > * URL : http://www.mercury.csse.unimelb.edu.au/ > > > > * License : GPL2 > > > > Programming Lang: Mercury > > > > Description : The Mercury programming system, a pure logical/functional programming language. > > > > > > This used to be in Debian some time ago, because I remember trying to > > > work on the package for some reason. I believe that it is > > > self-hosting[0], which may be a problem, except that it supposedly comes > > > with a C version of the compiler as well. To make life easy for porters, > > > I'd request that you always build the C compiler and then, if you want > > > to, bootstrap the Mercury compiler from that. > > > > > > If I'm remembering incorrectly, or that's no longer the case, feel free > > > to disregard this. > > > > > > > This is mostly correct. Mercury is indeed self-hosting and was > > previously included in Debian. Mercury has a number of different > > backends two of these target C, high-level C and low-level C. The > > Mercury source distribution includes C intermediate files for the > > standard library and compiler generated by the low-level C backend, > > these can be compiled with GCC to generate binaries which can be used to > > bootstrap an installation by re-compiling the Mercury sources. > > > > I have a working Debian package that builds and bootstraps Mercury from > > the source distribution. It requires gcc-3.4 as a build-depend and is > > able to bootstrap itself so that the resulting binaries are optimal on > > 32bit and 64bit machines (the explanation involves a discussion of > > tagged pointers). > > Hi, > > gcc-3.4 is about to be removed from Debian (#536777). How do you plan to > deal with that? We use a comple of GCC extensions that cause problems with more recent versions of GCC, we can turn those off or use the high-level C backend. Either way, we can deal with it but we mightn't like to :-) since in some cases it will make things slower, and we don't as yet have a way to prevent this in profiling and debugging builds.
Attachment:
signature.asc
Description: Digital signature