Skip to content

Upgrade Toolshed 2.5 -> 2.6.0 and BASIC-To-6809 v5.33 -> v5.35 - #76

Merged
jamieleecho merged 1 commit into
mainfrom
build/upgrade-toolshed-and-basto6809
Aug 14, 2026
Merged

Upgrade Toolshed 2.5 -> 2.6.0 and BASIC-To-6809 v5.33 -> v5.35#76
jamieleecho merged 1 commit into
mainfrom
build/upgrade-toolshed-and-basto6809

Conversation

@jamieleecho

Copy link
Copy Markdown
Owner

Upgrades two pinned tools to their current upstream releases.

Toolshed v2_5 -> v2.6.0

Upstream switched to dotted tag names, and v2.6.0 reworked the unix Makefile to
use a standard prefix/bindir/docdir that honours DESTDIR against
/usr/local, instead of hardcoding $(DESTDIR)/usr/bin.

That retires the workaround in the stage. Rather than installing into the real
prefix and then hand-copying ten named binaries plus the share directory into
/staging, the stage now just installs with DESTDIR=/staging, which is what
the comment there had been apologising for. The installed set is unchanged --
upstream's APPS list is exactly the set the old loop copied. (casm exists in
the tree but upstream still doesn't build it, in either version.)

One path moves as a result: ToolShed.html now lands in
/usr/local/share/doc/toolshed/ rather than /usr/local/share/toolshed/. That
is upstream's new docdir, not a choice made here, and it matches the
convention basto6809.pdf already uses. Nothing in the repo referenced the old
location.

BASIC-To-6809 v5.33 -> v5.35

The repo has no tags, so it stays pinned by SHA with the version carried in the
zip name. v5.35 is the only release left in Binary_Versions/ -- 5.33 has since
moved to Old_Versions/. Confirmed that Manual.pdf and both arch zips exist
at the new SHA and that the archive's internal directory name is unchanged, so
the sparse-checkout and unzip/mv paths still hold.

Verification

Run locally on arm64:

  • make lint -- shellcheck + hadolint clean.
  • Both changed stages build; Toolshed's own unit tests pass during its build.
  • Banners confirm the versions: decb from Toolshed 2.6.0, BasTo6809 ... V5.35.
  • Ran the integration the two tools share -- basto6809todsk HELLO.BAS driving
    BasTo6809 -> lwasm -> decb dskini/copy/attr -- producing a DSK that
    decb dir reads back.

Only the two changed stages were built, not a full make build && make test,
which pulls in the ~30-minute MAME compile. Worth a CI run for the x86_64 zip
path, since only the arm64 one could be exercised locally.

No version bump here -- those land on main separately.

🤖 Generated with Claude Code

Toolshed v2.6.0 gives its unix Makefile a standard prefix/bindir/docdir and
honours DESTDIR against /usr/local, instead of hardcoding $(DESTDIR)/usr/bin.
That retires the workaround in the stage: rather than installing into the real
prefix and hand-copying ten named binaries plus the share directory into
/staging, the stage now just installs with DESTDIR=/staging. The installed set
is unchanged -- upstream's APPS list is exactly the set the old loop copied.

One path moves as a result: ToolShed.html now lands in
/usr/local/share/doc/toolshed/ rather than /usr/local/share/toolshed/, which
is upstream's new docdir and matches the convention basto6809.pdf already
uses. Nothing in the repo referenced the old location.

BASIC-To-6809 has no tags, so it stays pinned by SHA with the version carried
in the zip name; v5.35 is the only release left in Binary_Versions (5.33 has
since moved to Old_Versions). The archive's internal directory name is
unchanged, so the sparse-checkout and unzip paths still hold.

Verified on arm64: make lint is clean, both stages build (Toolshed's own unit
tests pass during the build), the banners report Toolshed 2.6.0 and BasTo6809
V5.35, and basto6809todsk still drives BasTo6809 -> lwasm -> decb to produce a
DSK that decb dir reads back.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jamieleecho
jamieleecho merged commit f065b11 into main Aug 14, 2026
9 checks passed
@jamieleecho
jamieleecho deleted the build/upgrade-toolshed-and-basto6809 branch August 14, 2026 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant