[Openmcl-devel] Error Rebuilding CCL

Ron Garret ron at awun.net
Thu Jul 24 11:10:35 PDT 2008 

I'm not just shooting in the dark here.  We actually faced a nearly  
identical problem with a configuration file that had to be locally  
modified for every installation.  The svn/live idea worked like a charm.

rg

On Jul 24, 2008, at 10:57 AM, 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20080724/0fe25db9/attachment.htm>

More information about the Openmcl-devel mailing list