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

Re: Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.



On Tue, Jul 28, 2009 at 08:35:14AM +0200, Reinhard Tartler wrote:
> Paul Bone <pbone@csse.unimelb.edu.au> writes:
> 
> > 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).
> >
> > I hope that this will be acceptable by the Debian project and that
> > distributing intermediate files in the .orig.tar.gz file is not a
> > problem.
> 
> The same applies to the package aspectc++, a package that I maintain
> since some time. AspectC++ is a language extension for C++ for aspect
> oriented programming (AOP). It is built on top of an C/C++ Parsing and
> Manipulation framework (PUMA), where some functionality (e.g. support
> for various GNU language extension) is implemented using AspectC++
> aspects. There you have a pretty similar situation, and I'm doing a very
> similar approach: Shipping intermediate files that can be processed with
> gcc.
> 
> I suggest that you use these intermediate files only for compiling an
> intermediate compiler for bootstrapping. With that compiler, redo all
> intermediate files and build the binaries of the compiler that will
> eventually end up in the package. This ensures that you'll end with a
> working compiler on all architectures.

Yep,  That's what we do.

> BTW, this approach was actually suggested to me by Lamont Jones a few
> years ago. It seems to be a quite common approach, FWIW.

Thanks.

Attachment: signature.asc
Description: Digital signature


Reply to: