[Openmcl-devel] moving Clozure CL to GitHub

[Gail Zacharias]

The one-step install is not the only issue.  We have a self-bootstrapping
system.  If something breaks and isn't discovered for a while, it's useful
to be able to back out of the broken binaries into an earlier version.  So
while github might not be the right place, the binaries do need to be
stored and version-tracked somewhere, in a way that's correlatable with the
sources.

On Fri, Feb 10, 2017 at 10:22 AM, R. Matthew Emerson <rme at acm.org> wrote:

>
> > On Feb 9, 2017, at 10:48 PM, Ron Garret <ron at flownet.com> wrote:
> >
> >
> > On Feb 9, 2017, at 7:39 PM, R. Matthew Emerson <rme at acm.org> wrote:
> >
> >> I still have not come up with a brilliant idea to solve the problem of
> distributing bootstrapping images and interface databases for each of the
> supported platforms.
> >
> > Can you explain why this is any more of a problem with git than it was
> with subversion?
>
> Back when OpenMCL was still in CVS, the way to get a copy was a multi-step
> process.
>
> 1. get sources (via checkout or via downloading a file, e.g.,
> openmcl-src-0.12.tar.gz)
>
> 2. get interface databases (so that stuff like (#_getpid) will work) by
> downloading, e.g., openmcl-interfaces-0.4.tar.gz
>
> 3. get bootstrapping image (e.g., openmcl-darwinppc-bin-0.12.tar.gz) in
> order to have a lisp to compile the sources
>
> When we switched to Subversion, we were able to do two things:
>
> 1. Check in interface databases and bootstrapping binaries
>
> 2. (Ab-)use externals so that it is possible to get sources, interface
> databases, and bootstrapping binaries in a single command
>
> Subversion supports binaries fairly well: it can diff them and store
> deltas.  Since it's a centralized system, it doesn't matter if the
> repository gets large, because checking out a working copy doesn't have to
> copy the whole repository.
>
> Git is less suited to storing binaries.  It stores them whole (i.e., it
> doesn't diff them), and since cloning a git repository copies the entire
> repository, bloating the repository with binaries is a real concern.
>
> In summary, I think that having a one-command way to get a working CCL is
> a good feature.  I have never liked the way we abuse externals to do that,
> but the get-ccl-with-one-command feature seemed valuable enough that it was
> worth it anyway.
>
> Ideally, I'd like to make it equally easy to get a working CCL when we're
> on GitHub.   That's what I'm trying to figure out how to do.  It may be
> that I can preserve a one-step way to get CCL.  Or it might be necessary to
> a) get source and then b) get interfaces & bootstrapping image.  I'm
> hopeful that GitHub releases will be a good enough tool for this.
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20170210/9e3dedcb/attachment.htm>