[Openmcl-devel] Error Rebuilding CCL

[Ron Garret]

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