[Openmcl-devel] Error Rebuilding CCL

Gary Byers gb at clozure.com
Thu Jul 24 12:47:14 PDT 2008 

We do something like what Ron suggested on a branch that we maintain
for a customer; 'kernel-bootstrap' and 'image-bootstrap' are under
svn control, 'kernel' and 'image' are svn:ignore'd, and when there's
a new -bootstrap file you have to (a) notice and (b) remember to
cp it.

It's not clear that that's a whole lot different from the current
scheme, where you have to (a) notice and (b) remember to 'svn revert'.
The current scheme does have the advantage that a fresh svn checkout
works; neither scheme seems perfect.  Having used both, I think
that neglected to notice when binaries change about as often in
both cases.  (One gets in the habit of just doing 'svn update' -
since binaries don't change all that often - and not always paying
close attention to what scolls by.)

There's an unfinished UPDATE-CCL function (it's intended to be called
via (REBUILD-CCL ... :UPDATE T)) that'd do an 'svn update' for you
(it was written when we were still supporting CVS) and Mikel's been
working on an IDE memu item that does an update and rebuilds everything.

I kind of like the idea of having these tools do 'svn revert' for you
by default (though if these tools always dtrt for you there's some risk
that you forget about the issue whenever you use svn in the shell/emacs/
whatever.)

I think that this all means that as a binary distribution mechanism,
svn is a pretty good source control system.

Maybe someone else has a different opinion, but having used both
the scheme that's used in the trunk (binaries don't get updated)
and a scheme that distinguishes between 'working' binaries and
'svn-controlled' binaries, I think that I don't see a clear winner
(I forget/lose about as often in both cases) and see the scheme
used in the trunk as being very slightly preferable (if only because
it makes fresh checkouts a little simpler.)

On Thu, 24 Jul 2008, Chris Van Dusen wrote:

> svn:ignore might be something that could be used to accommodate this.
> Putting just enough thought into it to be dangerous, the live-image could be
> ignored and the svn-image would be used as Ron stated.  But,  that's just me
> shooting in the dark.  Maybe it'll give someone an idea.
>
> Chris.
>
> On Thu, Jul 24, 2008 at 11:52 AM, Ron Garret <ron at awun.net> wrote:
>
>> I suggest modifying the build procedure so that the binaries in SVN
>> are not used directly, but are copied (or symlinked) before they are
>> used.  In other words, you'd have two files "svn-image" and "live-
>> image".  When you bootstrap, you copy svn-image into live-image.  When
>> you build, you create a new live-image.  When you want to make a new
>> distribution (and only then) you copy live image back onto svn-image.
>> Only svn-image is actually checked in.  I believe that would eliminate
>> this problem.
>>
>> rg
>>
>> On Jul 24, 2008, at 4:13 AM, Chris Van Dusen wrote:
>>
>>> And that was indeed the case.  Thanks!
>>>
>>> Regarding reverting only those files that are in conflict, short of
>>> scripting it, I don't know of a way.
>>>
>>> Chris.
>>>
>>> On Jul 24, 2008, at 4:56 AM, Gary Byers wrote:
>>>
>>>> The "couple of days" that Matt mentioned in:
>>>>
>>>> <http://clozure.com/pipermail/openmcl-devel/2008-July/008389.html>
>>>>
>>>> might have been a little optimistic (e.g., the trunk is still
>>>> pretty volatile as he merges several months' worth of IA-32 changes
>>>> into it.)
>>>>
>>>> As of Wednesday afternoon, the trunk does build on Darwin/x8664
>>>> (with recent images; the most recent Darwin/x8664 image was checked
>>>> in as r10191 and identifies itself as "1.2-r10180M-trunk".)
>>>>
>>>> The fact that SVN handles binary files reasonably well is a good
>>>> thing,
>>>> but one common case that comes up often involves binary files to
>>>> which
>>>> you've made local modifications (the lisp kernel and heap image
>>>> usually
>>>> fall into this category.)  "svn update" downloads newer files and
>>>> stores
>>>> them in a parallel directory hierarchy (.svn directories), then
>>>> compares
>>>> them to the corresponding files in your working copy.  If your local
>>>> copy wasn't modified since it was last checked out, it's overwritten
>>>> with the new copy.  If a text file was modified, svn will try to
>>>> automatically reconcile the changes in your version with the new
>>>> version;
>>>> if it can, you get a working merged version and if it can't, it flags
>>>> the file as "conflicting" and adds some annotations that indicate
>>>> which
>>>> parts of the attempted merge came from which version.
>>>>
>>>> If a binary file's in conflict ... well, a binary merge would be an
>>>> interesting research project.  Since it can't really do any sort
>>>> of binary merge, svn leaves the locally modified copy alone and
>>>> notes that a conflict exists.  (Even if you've never changed the
>>>> source, a lisp heap image that you make yourself may not be bit-for-
>>>> bit
>>>> identical to the same version from the server: some internal
>>>> pathnames
>>>> may be different, there may be timestamps somewhere, ...)
>>>>
>>>> You can see those conflicts by doing:
>>>>
>>>> shell> cd ccl           # your working copy
>>>> shell> svn status
>>>>
>>>> I'd guess that "svn status" sould show something like
>>>>
>>>> C    dx86cl64.image
>>>>
>>>> and maybe
>>>>
>>>> C    dx86cl64
>>>>
>>>> indicating that "svn update" didn't really know how to merge the
>>>> locally-modifed copy.
>>>>
>>>> 'svn update' has already downloaded a copy of everything in the
>>>> repository (and stored it in a .svn directory), so you can do:
>>>>
>>>> shell> svn revert dx86cl64.image
>>>>
>>>> which basically says "discard my local modifications to the specified
>>>> file and replace the working copy with the last version obtained from
>>>> the server."
>>>>
>>>> If there's a convenient way to say "do 'svn revert' on all files
>>>> that 'svn status' reports as being in conflict", I don't know what
>>>> it is.
>>>>
>>>> Anyway, the symptom is "trying to use an old image to compile new
>>>> sources", and if you just did an "svn update" and still have
>>>> an old image, this is a plausible explanation.  Binary files
>>>> don't change that often, but when they do it's necessary to be
>>>> aware of the fact that svn can't do much but (conservatively)
>>>> not update the working copy.
>>>>
>>>> On Wed, 23 Jul 2008, Chris Van Dusen wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to rebuild bleeding edge CCL from the command line
>>>>> (Leopard, X86_64), and am getting the following:
>>>>>
>>>>> ? (ccl:rebuild-ccl :full t)
>>>>> ;Building lisp-kernel ...
>>>>> ;Kernel built successfully.
>>>>> ;Compiling "/Users/chrisvandusen/bin/ccl/compiler/nxenv.lisp"...
>>>>> ;Loading #P"/Users/chrisvandusen/bin/ccl/bin/nxenv.dx64fsl"...
>>>>> ;Compiling "/Users/chrisvandusen/bin/ccl/compiler/nx.lisp"...
>>>>> ; Including "/Users/chrisvandusen/bin/ccl/compiler/nx-basic.lisp"...
>>>>> ; Including "/Users/chrisvandusen/bin/ccl/compiler/lambda-
>>>>> list.lisp"...
>>>>> ; Including "/Users/chrisvandusen/bin/ccl/compiler/nx0.lisp"...
>>>>> ; Including "/Users/chrisvandusen/bin/ccl/compiler/nx1.lisp"...
>>>>> ;Compiler warnings for "/Users/chrisvandusen/bin/ccl/compiler/
>>>>> nx0.lisp" :
>>>>> ;   In MAKE-AFUNC: Undefined function %MAKE-AFUNC
>>>>> ;Loading #P"/Users/chrisvandusen/bin/ccl/l1-fasls/nx.dx64fsl"...
>>>>> ;Compiling "/Users/chrisvandusen/bin/ccl/compiler/
>>>>> optimizers.lisp"...
>>>>>> Error: Undefined function %MAKE-AFUNC called with arguments () .
>>>>>> While executing: MAKE-AFUNC, in process listener(1).
>>>>>> Type :GO to continue, :POP to abort, :R for a list of available
>>>>> restarts.
>>>>>> If continued: Retry applying %MAKE-AFUNC to NIL.
>>>>>> Type :? for other options.
>>>>> 1 >
>>>>>
>>>>>
>>>>> The warning seems a foreshadowing of the error to come, but that's
>>>>> just me guessing.  If there's any more info that might be helpful,
>>>>> let
>>>>> me know.
>>>>>
>>>>> Thanks,
>>>>> Chris.
>>>>> _______________________________________________
>>>>> Openmcl-devel mailing list
>>>>> Openmcl-devel at clozure.com
>>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>

More information about the Openmcl-devel mailing list