|
1 | | -# How to build a medley release |
| 1 | +# How to Build Medley and make a Release |
2 | 2 |
|
3 | | -Originally done only with shell scripts: |
4 | | -``` |
5 | | -./scripts/loadup-all.sh |
6 | | -``` |
7 | | -to make the loadups |
| 3 | +# Using GitHub actions |
| 4 | + |
| 5 | +In the GitHub medley repository (Interlisp/medley) go to the Actions tab. |
| 6 | + |
| 7 | +It will list the available GitHub actions. |
| 8 | +Select: **Build/Push Release & Docker**. |
| 9 | + |
| 10 | +In the middle of the screen there is a box labeled "Workflow Runs". |
| 11 | +There should be a row in it that states 'This workflow has a workflow_dispatch event trigger' with a drop down menu (it really looks more like a button) on the right side labeled 'Run workflow'. Select that and you'll get a form allowing you to select the branch (I've only used Master) and enter the release name. Enter a name or leave it empty and press the green 'Run workflow' button. The workflow should queue up and run. |
| 12 | + |
| 13 | +Build/Push Release & Docker first builds Maiko and Medley, pushes a Medley release to the Interlisp/medley repo Releases, then makes a Docker image. |
| 14 | + |
| 15 | +The files in .github/workflows/ contain the details. |
| 16 | +<!-- |
| 17 | +The workflow pulls the latest Maiko image from Docker Hub and the Release Assets from the latest Medley release, generally defined as medley-YYMMDD. The Medley Docker image adds in Tight VNC Server and retrieves the two tarballs associated with a release, one containing the sysouts and the other the other needed files source, fonts, etc. The contents are uncompressed and loaded into the Medley directory structure. |
| 18 | +--> |
| 19 | + |
| 20 | +# Building Medley for yourself |
| 21 | + |
| 22 | +The actual building itself is done with various shell scripts, found in the `scripts` directory in the medley repository. Most of the scripts have a minimal sanity check that they are being run from the medley repository. |
| 23 | + |
| 24 | +Historically, building the medley image (called a "sysout") was called "doing a loadup". Back in the day, a loadup took the better part of a day, and no one would do the whole thing -- there was no automation. |
| 25 | + |
| 26 | +## Prerequisites |
| 27 | + |
| 28 | +In these instructions, there is an assumption that the loadup scripts can find other repositories. All of the loadup scripts have to find `lde` and `ldex` or `ldisdl` and also `ldeinit`. |
| 29 | + |
| 30 | +Loadups use the run-medley script, which looks for Maiko (actually the lde & ldeinit executables) as follows: |
| 31 | + |
| 32 | +1. lde (ldeinit) on PATH |
| 33 | +2. In the `<osversion>.<machinetype>` subdirectory of the directory specified by the $MAIKODIR environment variable |
| 34 | +3. In the `<osversion>.<machinetype>` subdirectory of the directory specified by $MEDLEYDIR/../maiko/ |
| 35 | +4. In the `<osversion>.<machinetype>` subdirectory of the directory specified by $MEDLEYDIR/maiko/ |
| 36 | + |
| 37 | +where $MEDLEYDIR is the directory from which you called the loadup script. |
| 38 | + |
| 39 | +## Make everything |
| 40 | + |
| 41 | +The shell command: |
8 | 42 | ``` |
9 | | -./scripts/loadup-and-release.sh |
| 43 | +time ./scripts/loadup-all.sh -apps && time ./scripts/loadup-db.sh |
10 | 44 | ``` |
11 | | -to go on to make the tgz files and release them |
| 45 | +does everything; on a fast machine it takes 4-6 minutes, most of which is spent in the `loadup-db.sh` step. Without the `loadup-db.sh` step, it runs in 22 seconds on a fast system. |
12 | 46 |
|
13 | | -# Using github actions |
| 47 | +## How loadup-all.sh works |
14 | 48 |
|
15 | | -In the github medley repository (Interlisp/medley) go to the Actions tab. |
| 49 | +You don't need to know this unless you want to change some of the low-level files involved. |
16 | 50 |
|
17 | | -It will list the available github actions, select: **Build Medley Release**. |
| 51 | +The script "loadup-all.sh" itself involes scripts used for different steps in the loadup -- basically loadup-all calls the scripts in this order: |
18 | 52 |
|
19 | | -In the middle of the screen there's a box labeled workflow runs. |
20 | | -There should be a row in it that states 'This workflow has a workflow_dispatch event trigger' with a drop down menu (it really looks more like a button) on the right side labeled 'Run workflow'. Select that and you'll get a form allowing you to select the branch (I've only used Master) and enter the release name. Enter a name or leave it empty and press the green 'Run workflow' button. The workflow should queue up and run. |
| 53 | +* `loadup-init.sh` |
| 54 | +* `loadup-mid-from-init.sh` |
| 55 | +* `loadup-lisp-from-mid.sh` |
| 56 | +* `loadup-full-from-lisp.sh` |
| 57 | +* `loadup-aux.sh` |
| 58 | +* `loadup-apps-from-full.sh` |
| 59 | +* `loadup-db.sh` |
| 60 | +* `copy-all.sh` |
21 | 61 |
|
22 | | -# How to create a Docker image for the latest Medley release |
| 62 | +These are explained in reverse order: |
23 | 63 |
|
24 | | -In the github medley repository (Interlisp/medley) go to the Actions tab. |
| 64 | +### `copy-all.sh`: copy files from build directory to loadups |
25 | 65 |
|
26 | | -It will list the available github actions, select: **Build Medley Docker image**. |
| 66 | +Most of the scripts build things in a temporary directory and, if the entire process succeeds, copies the results to the `loadups` directory. The environment variable `LOADUP-OUTDIR`, if set, is used, otherwise a sub-directory of /tmp. |
27 | 67 |
|
28 | | -A table is presented which lists the previous runs of the workflow. If the workflow has never been run, it will be empty. A the top of the list is a row labeled, 'This workflow has a workflow_dispatch event trigger.' with a drop down menu labeled 'Run workflow'. Select it. |
| 68 | +`copy-db.sh` and `copy-full.sh` are provided if you've only done partial loadups. |
29 | 69 |
|
30 | | -A box will be presented asking, 'Use workflow from' with a drop down menu of all available branches. The default branch is **master**. Leave it selected and push the green 'Run workflow' button. |
| 70 | +`cpv` is a script that copies a file from one place to another while maintaining Medley version numbering. |
31 | 71 |
|
32 | | -The workflow will be queued to run and start running. |
| 72 | +### `loadup.db`: build `fuller.database` |
| 73 | + |
| 74 | +This step was added to make a Masterscope database of "everything". The result is a file `fuller.database`. This was an artifact of an attempt to build some diagnostic tools to help understand what was going on in Medley. There is a 4 step process in the `GATHER-INFO` function in the file `MEDLEY-UTILS` in the `internal` subdirectory of the medley repository that ends with creating a masterscope database after loading all of the source files for every file that is part of the loadup, plus a few additional LispUsers files listed in variables that are part of `MEDLEY-UTILS`. |
| 75 | + |
| 76 | +There are some problems that `GATHER-INFO` results hint at, but haven't been explored systematically. |
| 77 | + |
| 78 | +Masterscope has some gaps and bugs so `fuller.database` isn't as useful as it could be. For example, Masterscope 'show paths' was written assuming you had only anlayzed the parts you were working on, and so the results of `SHOW PATHS` are too big to be useful. |
| 79 | + |
| 80 | +## `loadup-aux.sh`: rebuild two files used for Medley development |
| 81 | + |
| 82 | +`exports.all` is a collection of external declarations from a set of files in the medley/sources directory that are marked as being exported within those sources. Low level system declarations that aren't needed by most users. The files that need exports.all are generally loaded by loading `SYSEDIT`, which sets up a couple of preferences and then loads `exports.all`. |
| 83 | + |
| 84 | +`whereis.hash` is an index file mapping function, variable, record declarations and other components to the file name containing that definition. It is the result of scanning the directories in the medley repository, including lispusers and library and internal etc. (but not obsolete?). |
| 85 | + |
| 86 | +### `loadup-apps-from-full.sh:`build `apps.sysout` |
| 87 | + |
| 88 | +`apps.sysout` includes some other components that are part of online.interlisp.org experience. |
| 89 | + |
| 90 | +### `loadup-full-from-lisp.sh`: Build a `full.sysout` and |
| 91 | + |
| 92 | +`full.sysout` Includes what we hope is a useful subset of Interlisp library and lispusers components as well as our modernization components. |
| 93 | + |
| 94 | + |
| 95 | +### Build a `lisp.sysout` in 4 scripts: |
| 96 | + |
| 97 | +### `loadup-lisp-from-mid.sh` build `lisp.sysout` |
| 98 | + |
| 99 | +`lisp.sysout` is what most 1990s customers started with. This step starts with `init-mid.sysout` and runs `sources/LOADUP-LISP`. |
| 100 | + |
| 101 | +### `loadup-mid-from-init.sh` build `mid.sysout` |
| 102 | + |
| 103 | +This step uses a Maiko that has been compiled with the `init` option. It reads the `init.dlinit` and initializes the package system and runs the EXPRESSIONS from the files that were "loaded" by MAKEINIT, and writes out `init-mid.sysout`. |
| 104 | + |
| 105 | +### `loadup-init.sh`: build `mid.sysout` |
| 106 | + |
| 107 | +This step (called `MAKEINIT`) runs a Lisp program (using a `starter` sysout) that reads in Lisp sources for the bootstrap loader, walks through the code renaming the low-level memory management functions to work on a file instead of in memory. These renamed functions are written to a file (called I-NEW), and I-NEW is then compiled and loaded in and run to 'virtually' load the core set of files in an initial memory image (called INIT.SYSOUT). It then does another (theoretically unnecessary) pass of reading in INIT.SYSOUT using a different renaming of variables used originally for remote debugging (called TELERAID) and moving some pages around to make room for Dandelion IO Processor boot code. |
| 108 | + |
| 109 | +While this step requires an Interlisp implementation, it isn't necessarily a Medley implementation. If you want to change the instruction set or modify any data structures that are reflected in both the Lisp code and Maiko, you can run this part in an older Interlisp. Theoretically. |
33 | 110 |
|
34 | | -The workflow pulls the latest Maiko image from Docker Hub and the Release Assets from the latest Medley release, generally defined as medley-YYMMDD. The Medley Docker image adds in Tight VNC Server and retrieves the two tarballs associated with a release, one containing the sysouts and the other the other needed files source, fonts, etc. The contents are uncompressed and loaded into the Medley directory structure. |
|
0 commit comments