[Openmcl-devel] How about Git?

Gail Zacharias gz at clozure.com
Mon Nov 30 11:49:42 PST 2015

One approach I haven't seen discussed (so perhaps it has a fatal flaw I
don't know about) is for distribution to be done via a tarball that
consists of the binary distribution plus a skeleton version control tree -
i.e. a source tree checked out the central repo, but with all the files
deleted, so just the vcs meta-data. Installation consists of unpacking the
tarball, and then (by hand or via a script) issuing the appropriate vcs
command to fetch the latest sources, and finally rebuilding the images from
source.  By including the vcs meta-data in the tarball, you eliminate the
failure mode of users not knowing where to get the sources, or getting the
wrong version of the sources (although it doesn't eliminate the problem of
users getting just the sources and not knowing how to get the binaries,
which also used to happen, but that's more manageable).

On Mon, Nov 30, 2015 at 1:45 PM, Gary Byers <gb at clozure.com> wrote:

> in 1993, my boss was excited to get a shiny new Solaris box and asked me
> to try to get gcc
> running on it.  gcc sources were freely available, but (unlike earlier
> SunOS versions Solaris
> did not bundle a C compiler, rendering those sources less useful than they
> would otherwise
> have been.
> CCL is mostly written in CCL, and you need a recent version of CCL to
> bootstrap a new version.
> whether one does
> git clone-or-whatever some-url       to get sources
> git something different                    to get platform-specific
> binaries into the the same place
> doesn't seem very difficult, but neither did using a vcs and tar files.  I
> was wrong about that.
> On 11/30/2015 09:47 AM, Dmitry Igrishin wrote:
> 2015-11-30 19:20 GMT+03:00 Gary Byers <gb at clozure.com>:
>> On 11/30/2015 08:29 AM, Stelian Ionescu wrote:
>> If you want to keep the master copy in SNV and mirror to git, SubGit can
>> do that but mapping externals to submodules is not supported:
>> <http://www.subgit.com/remote-book.html>
>> http://www.subgit.com/remote-book.html chapter 9.
>> If you want to keep the master copy in git and access it through SVN,
>> Github supports that:
>> <https://help.github.com/articles/support-for-subversion-clients/>
>> https://help.github.com/articles/support-for-subversion-clients/. Again,
>> mapping submodules to externals is not supported.
>> That said, as far as I understand it, there are two reasons why binaries
>> are bundles with the sources:
>> 1) for easy distribution of released binaries together with the code so
>> that those who only use releases can also M-. (or equivalent) without
>> hassles.
>> 2) for easy bootstrap because of compiler and/or ABI(such as fasl format)
>> changes within a release.
>> Several years ago this was essentially how CCL was distributed - one
>> checked out sources from CVS and a
>> a matching tarball via FTP or equivalent, and that was it.  At the time,
>> there were two possible choice of
>> tarballs., one for 32-bit PPC Linux and another for 32-bit PPC Darwin.
>> Some of the smartest people that I've ever known were very confused by
>> this, and I think that having
>> a single way for users to obtain a consistent set of sources and binaries
>> is very important.  SVN offers
>> this via "external properties", which are otherwise a mess.  If Git does
>> as well, I have not seen anyone
>> describe the mechanism.
>> I don't otherwise care whether one uses "svn co something" or "git clone
>> something", but I would
>> not want to expect users to have to revert back to what didn't work well
>> long ago.
> I don't know about CCL, but the GCC source distribution comes with a simple
> download_prerequisites shell script which downloads via wget MPFR, GMP,
> MPC libraries
> before building GCC. This works fine for many years. So, why not use this
> approach with CCL?
> There are "hooks" system in the Git, which are event-based. It's possible
> to
> run the script for download actual binary files after git clone or git
> merge or git pull
> operations (post-checkout and post-merge hooks).
> _______________________________________________
> 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/20151130/ad1db36e/attachment.htm>

More information about the Openmcl-devel mailing list