[Openmcl-devel] A Debian packaging update and an outstanding issue

[Pascal J. Bourguignon]

Faheem Mitha <faheem at faheem.info> writes:

> On Mon, 13 Aug 2012 01:08:31 +0200, Pascal J. Bourguignon <pjb at informatimago.com> wrote:
>
>> You could instrument ccl with my all new stepper package, trace its
>> processing while compiling itself, reformat the output to make it
>> even more "human readable" (or modify my stepper to produce this
>> nicer output directly).  This would make a procedure that a human
>> could execute to produce the initial debian ccl binary.
>
>> An alternative would be to have a human just interpret the ccl
>> source code to compile ccl itself, but it may be too complex,
>> therefore too error risky.  The first procedure would have more
>> step, but they'd be simplier steps.
>
>> You could write a new target for ccl, that would produce C code
>> instead of binary code.  Make a cross compilation to that target,
>> and have debian people compile that C code with the gcc compiler the
>> compiled by had as described in the first procedure above.  They did
>> that once upon a time, didn't they?
>
> I'm afraid all this sounds miles over my head.
>
>> Because if they never did that, I'm afraid debian may be compromised:
>> http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
>>
>>
>>> The phrase "slightly older and compatible" is vague.
>
>> Try to compile gcc 4.5 with gcc 1.0.
>
> I really don't see how this is relevant. I'm not suggesting that the
> CCL developers support compilation of CCL by an ancient version of
> CCL.

There's also a vagueness in the path to upgrade gcc compilers.  You may
compile version X of gcc with some version X-ε of gcc, as long as ε is
small enough.  It's the same with ccl.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.