[Openmcl-devel] moving Clozure CL to GitHub

[Ron Garret]

On Feb 10, 2017, at 7: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.

My suggestion:

1.  Don’t store the binaries in the source tree.

2.  Separate the initial bootstrap case from the case where someone already has a working CCL on their system and wants to upgrade.

3.  In the case where someone wants to upgrade, write a CCL script that does the Right Thing.  Because CCL already has snarf-url built in this should not be hard.  I volunteer to write and maintain it.  The instructions for upgrading CCL should be: run upgrade-ccl.lisp.

4.  In the case where someone is downloading CCL for the first time there are two options: either bite the bullet and make it a two-step process, or write a Python or bash script that does the Right Thing.

Personally I think making it a two-step process makes sense.  Most people approaching CCL for the first time won’t care about the sources, they will want it to Just Work.  So keep pre-built binaries on a server somewhere for first-timers and updates, and keep the sources free of binaries.

rg