[Openmcl-devel] Error Rebuilding CCL
ron at awun.net
Thu Jul 24 18:10:35 UTC 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.
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.
> 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.
> 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
> >> copy wasn't modified since it was last checked out, it's
> >> 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
> >> 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-
> >> 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
> >> file and replace the working copy with the last version obtained
> >> 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-
> >>> ; 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel