[Openmcl-devel] Latest trunk (r13464) build issue??

[Gary Byers]

On Fri, 26 Feb 2010, Jon S. Anthony wrote:

> On Fri, 2010-02-26 at 09:48 -0700, Gary Byers wrote:
>>
>> On Fri, 26 Feb 2010, Jon S. Anthony wrote:
> ...
>> Just continue from the constant-redefinition CERROR (via :GO or (:C 2)).
>> If you choose to skip compiling the file, the fasloader will later
>> try to complain that the FASL file is missing; the lisp image that
>> this happens in is in the process of bootstrapping itself and hasn't
>> yet developed communication skills.
>
> OK, I'll do that.  But I'm curious - why is a X8632 target
> compiling/loading X8664-arch definitions?  The hack I tried (and seems
> to work for some value of "work") was to replace the x8664-arch.lisp
> file contents with just a defpackage "X8664" and an (in-package
> "X8664").

Including a file which defines a few X8664 constants in the X8632 build
(and vice versa) is done intentionally.  I honestly don't intend to be
rude here, but it would be pretty goddamned stupid if that was done by
accident or without good reason.

One of those constants was defined incorrectly; Matt fixed it several
weeks ago.  That particular constant influences how some calls to SBIT
are compiled; the affected cases are pretty obscure and don't have
any impact on how the lisp compiles itself.

A constant getting redefined is ordinarily slightly anomalous and usually
results in a CERROR.  (In the case of REBUILD-CCL, there's a fairly strong
argument in favor of quietly allowing the redefinition to occur, and the
trunk sources - which are more recent than the current trunk binaries -
offer an option that allows that.)

As

<http://trac.clozure.com/ccl/wiki/UpdatingFromSource>

notes (of the process of compiling newer sources with a slightly older image):

"There may be compiler warnings during compilation, usually related to
calls to functions that will be defined when the process finishes but
which are not yet defined during compilation (or which take a
different number of arguments at compile time than they will when the
image is built, etc.) Once in a while, some constants get redefined
and a continuable error is signaled; continue from the CERROR to use
the new value."

<http://trac.clozure.com/ccl/wiki/TrackingTheTrunk>

notes that warnings/constant redefinition CERRORs are more common in
the trunk (we actually do try to ensure that patches to the released
version compile without warnings or CERRORs.)

This is not unexpected behavior.  The trunk is generally intended for
public consumption, but we don't check in a few hundred MB of binaries
every time a trivial change causes a benign compiler warning or involves
a constant redefinition that might CERROR.

If compiling a released version caused lots of warnings and CERRORs, I
could easily understand why that would cause concern.  I don't think that
it's reasonable or practical to have the same expectation of the trunk,
and we try to say that "the trunk sources should generally build with
(possibly older) trunk binaries, but there may be warnings or CERRORs 
about things that aren't relevant to the build process."  As Gail noted,
there generally should -not- be warnings/CERRORs if one repeats the
REBUILD-CCL step with (now) up-to-date binaries.

I think of this as being pretty clearly spelled out (at least in those
Wiki pages), but enough people are surprised often enough that this must
not be as clear as I think it is.  The CCL trunk exists for a few reasons:

  1) to provide a way of introducing changes (that might be speculative/
     experimental in many cases) without breaking the released version.
  2) to make the current day-to-day version available to anyone interested
     in tracking new features/new bugs.

The second reason is certainly important, but it's frankly less
important than the first; one consequence of this is that it's far
more important that the trunk binaries can compile the trunk sources
than it is to ensure that they can do so without (irrelevant, benign)
warnings.

There's an inverse issue: when there are updated binaries in the
repository, the svn client generally needs to be told to overwrite
locally modified copies of those files; failure to do that overwriting
can cause bootstrapping problems.  This was a source of confusion
several months ago, but a new policy (wherein the first person to
report "the trunk doesn't build" because they're using stale binaries
owed me US $1, the next person owed me $2, the next $4 ...)  seems to
have eliminated much of that confusion.

Although it's been successful in that regard, this new policy has frankly
not made me nearly as rich as I'd hoped it would; I'd hoped to be able
to retire to a fairly large private island by now, and all I've gotten
out of it is a lousy IOU.  Obviously, people using the trunk need some
sort of reminder of the fact that trunk binaries aren't kept up to date
and that this may lead to benign warnings and (until we can suppress them)
occasional CERRORs on constant redefinition, and I think that the same
scheme might be expected to have a similar deterrent effect.

So, I'd be glad if people who use the trunk were aware of the issue and
stopped reporting expected behavior.  I'd be equally glad (for different
reasons) if 30 or so people forgot and reported "dog bites man!", as long
as those people pay promptly and in cash.