[Openmcl-devel] Error Rebuilding CCL

Thu Jul 24 11:47:31 PDT 2008

The shooting in the dark was directed more at the use of svn:ignore for
this.  Personally, I haven't used it, but Gary's comments about Subversion
put into my mind an approach that would leverage it's available tools.
Chris.

On Thu, Jul 24, 2008 at 1:10 PM, Ron Garret <ron at awun.net> wrote:

> 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
>>
>
>
>
> _______________________________________________
> 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/1d044b11/attachment.htm>