v3.0.0-dev

What's Changed

• docs: record the v2 baseline again (cc370 1.4.0, libc370 2.3.1, mbt 2.2.0) by @mgrossmann in #162
• docs(testing): drop the last startup = "crt1" from an example by @mgrossmann in #164
• feat(v3): mbt 3 core in Go -- build, deps, package, test, deploy, compared with v2 by @mgrossmann in #165
• feat(v3): mbt.toml schema 3 and mbt migrate by @mgrossmann in #166
• feat(v3): release, prerelease, the launcher, and release pipelines by @mgrossmann in #167
• feat(v3): Lua extensions -- hooks, tasks, commands; [tools]; mbt run, clean by @mgrossmann in #170
• feat(v3): targets -- ~/.mbt/targets.toml, one mvsMF session per run, mbt target by @mgrossmann in #176
• feat(v3): the console chain -- mvsMF first, the Hercules web console as fallback by @mgrossmann in #172
• feat(v3): plugins -- [plugins], pinned like dependencies, held to what they declare by @mgrossmann in #174
• feat(v3): a TN3270 client for interactive TSO tests by @mgrossmann in #173
• feat(v3): mbt test --tso -- interactive TSO tests in Lua over TN3270 by @mgrossmann in #177
• fix(v3): read the Hercules console reply in the format Hercules writes by @mgrossmann in #178
• docs: MIGRATION.md now takes a project from mbt 2 to mbt 3 by @mgrossmann in #179
• fix(v3): what the first two migrations found -- deploy, doctor, migrate, the guide by @mgrossmann in #180
• feat(v3): mbt target info says what Hercules is, as it does for mvsMF by @mgrossmann in #181
• fix(v3): commands without arguments refuse them; mbt version names its commit by @mgrossmann in #182
• ci: name the mbt release after its tag (v3.0.0-dev) by @mgrossmann in #183
• ci: build the mbt release outside the checkout, so no binary says +dirty by @mgrossmann in #185
• feat(v3): include/ by convention; mbt migrate leaves out what mbt does itself by @mgrossmann in #186
• fix(v3): refuse a default library name that is no data set name by @mgrossmann in #187
• fix(v3): the host test build gets mbt's warning flags too by @mgrossmann in #188
• fix(v3): mbt migrate notes include/ left out on its own, and drops the comment by @mgrossmann in #190
• fix(v3): say when GitHub's rate limit is the cause; mbt doctor --offline by @mgrossmann in #191
• fix(v3): refuse to compile while a declared dependency is not staged by @mgrossmann in #192
• feat(v3): C99 (gnu99) is the default dialect of an mbt.toml project by @mgrossmann in #193
• fix(v3): pin a tool per platform, all platforms at once by @mgrossmann in #194
• fix(v3): mbt migrate keeps the first test's comment, notes the defaults it leaves out by @mgrossmann in #195
• fix(v3): mbt migrate drops an emptied [deploy] with its comment; guide on project.toml readers by @mgrossmann in #196
• fix(v3): refuse to derive DELETE of the minor's id after a released patch by @mgrossmann in #197
• fix(v3): mbt deploy RECEIVEs a replaced library back onto its own volume by @mgrossmann in #198
• feat(v3): mbt deploy replaces members instead of deleting the library (mbt#105) by @mgrossmann in #201
• build: refuse two sources that compile to the same object by @mgrossmann in #202
• test --tso: t.testlib names the [deploy] test_target library by @mgrossmann in #203
• deploy --dry-run: describe the merge deploy, not the old delete by @mgrossmann in #204
• release: refuse to move a release tag, and a next version above 9 by @mgrossmann in #205
• cli: options anywhere among the arguments by @mgrossmann in #206
• deps: keep an override's pin under --update; accept [build.host] cc by @mgrossmann in #207
• docs(books): MBT User's Guide and Reference (ML02-0001, ML02-0002), with CI and release PDFs by @mgrossmann in #213
• smp: an explicit fmid needs an explicit delete by @mgrossmann in #214
• README: point to the MBT 3 manuals by @mgrossmann in #215
• docs(books): explicit fmid needs explicit delete; text libraries replaced by design by @mgrossmann in #216
• docs(books): recapture the ug-first deploy dry run with 3.0.0-dev by @mgrossmann in #217
• ext: ctx.project.deploy_target by @mgrossmann in #219
• docs: MIGRATION points to mbt-stc for compressing the development library by @mgrossmann in #220
• docs(books): ctx.project.deploy_target, and compressing on the restart with mbt-stc by @mgrossmann in #221
• mvsmf: log on again when a restarted server rejects the session by @mgrossmann in #223
• console: a 5xx from mvsMF may follow an issued command -- do not resend it by @mgrossmann in #224
• ext: point a description given as mbt.command's second argument to the table form by @mgrossmann in #225
• docs(books): mbt.command in its table form, with a description by @mgrossmann in #226
• build: refuse a NAME that is neither a module nor a test by @mgrossmann in #227
• ext: before_test hooks see ctx.kind by @mgrossmann in #228
• ext: a dry run fetches no tool, logs on for no token, keeps task signatures by @mgrossmann in #229
• deploy: build first by @mgrossmann in #240
• targets + ctx.mvs: further users, private sessions, Basic requests, headers by @mgrossmann in #241
• docs: migration -- own tools that import mbt 2's Python by @mgrossmann in #236
• test --tso: fixtures -- [tso.NAME] data sets loaded from the repo before the sessions by @mgrossmann in #244
• test --tso: a failed logoff is reported also after a failed test by @mgrossmann in #245
• mvsmf client: an error status comes back with its body by @mgrossmann in #247
• ci: install maclib370 into the sysroot in the toolchain workflows by @mgrossmann in #248
• ci: install maclib370 before the toolchain build; docs: fixtures in table form by @mgrossmann in #251
• build: COBOL sources through cobc370 by @mgrossmann in #252
• COBOL follow-ups: [lib]/[internal] sources, an old cobc370 named, CI input cobc370_ref by @mgrossmann in #254
• cobc370: the dependencies' include/ after the project's cobflags by @mgrossmann in #256
• test --mvs: a SYSOUT DD for tests with COBOL sources by @mgrossmann in #257
• deploy --reallocate: probe before the delete, stop the size from compounding by @mgrossmann in #259
• COBOL units: no entry needed when a C source defines main() by @mgrossmann in #260
• test --mvs: load fixtures with DD DATA, not DD * by @mgrossmann in #262
• test --tso: larger terminals -- models 3, 4, 5 and oversize screens by @mgrossmann in #263
• targets: auth = "basic" -- mvsMF without a session by @mgrossmann in #264

Full Changelog: v2.2.0...v3.0.0-dev

v2.2.0

mbt is the build tool for C and S/370 assembler projects that target MVS 3.8j: a project's Makefile is two lines, everything else is in project.toml, and compile, assemble, link and package all run on the host with the cc370 toolchain.

2.2.0 changes how a C module gets its startup. libc370 2.3.0 moved the C startup (@@CRT0) into libc.a, so mbt no longer links a startfile: the entry point decides, and the archive supplies it. It also makes the choice of @@START explicit instead of an accident of archive order. Requires cc370 >= 1.2.0; tested with cc370 1.4.0 and libc370 2.3.1.

Read this first

• startup = "crt0" / "crt1" can go. Both now mean "no explicit startfile"; mbt warns once per project while a module still names them. Drop the key together with a [toolchain] libc370 pin of at least 2.3.0: against an older libc370, a module without the key falls back to crt0.o.
• A dependency that defines @@START now needs a decision. libc370 is searched ahead of every dependency, so each module gets libc370's @@START unless it says dep_startup = true. If a dependency archive defines @@START and a module sets neither true nor false, make stops with exit 2 and names both. A CGI module that relies on its server's launcher sets dep_startup = true.
• An unknown startup value is an error (exit 2). It used to become crt0 silently.
• startup = false (own entry point) and startup = "crtm" are unchanged.
• A C module's startup no longer sits at offset 0 of the load module; the directory entry points at it. Anything that branches to a module's load point instead of its entry point would notice.

What changed

	before (2.1.x)	now (2.2.0)
C startup	crt0.o / crt1.o named on the link line	@@CRT0 taken from libc.a by the entry point
@@START	whichever archive came first; dependencies could win silently	libc370 first; a dependency's only with dep_startup = true
dependency defines @@START, module silent	built green with the wrong one	exit 2, naming module and archive
startup = "crt1"	the startfile without the thread driver	deprecated, one warning per project
unknown startup value	treated as crt0	configuration error
sysroot detection	by crt0.o	by libc.a, older sysroots still found
libc370 without @@CRT0 in libc.a	—	linked as before, with one warning

Install

mbt is consumed as a git submodule:

git -C mbt fetch --tags
git -C mbt checkout v2.2.0
git add mbt

Then remove startup = "crt0"/"crt1" from project.toml, pin [toolchain] libc370 = "2.3.1" (or at least 2.3.0), and add dep_startup where make asks for it. docs/MIGRATION.md describes the model in full.

Changelog

• The C startup comes out of libc.a; startup = becomes optional, the entry point decides (#158).
• libc370's @@START first for modules and tests; dep_startup selects a dependency's (#62).
• Sysroot found by libc.a; a cc370 floor of 1.2.0 when the CRT comes from the archive; one warning on an older libc370 (#160).
• docs/MIGRATION.md: ld370's default since cc370 1.2.0 and what each startup is for (#157); maintainer documentation moved to internals/ (#155, #156).

v2.1.3

mbt is the build tool for C and S/370 assembler projects that target MVS 3.8j: a project's Makefile is two lines, everything else is in project.toml, and compile, assemble, link and package all run on the host with the cc370 toolchain.

2.1.3 is a drop-in update within 2.1.x. It makes the check for writable data in reentrant modules see what it missed before. Tested with cc370 1.2.0 and libc370 2.2.0. From cc370 1.2.0 on, a module whose project declares no attributes is linked with neither RENT nor REUS, so declare them.

Read this first

• A test declared rent = true that includes mbtcheck.h now fails the build. mbtcheck.h keeps its pass/fail counters in static storage, and statics in headers are now checked. Declare such tests rent = false (tests are not shared between tasks, so nothing is lost).
• Data in [internal] sources is now reported as a warning whenever any module may be RENT. Before, it was reported only when some other finding existed. Which module links which internal object is not known before the link, so these remain warnings.
• make module-data MODDATA_ARGS=--all lists every finding; the build shows three warnings per module.

What changed

	before (2.1.2)	now (2.1.3)
a static in a project header	not seen	reported against the header, once per module
system headers (the libc370 sysroot)	not scanned	still not scanned
[internal] data	only reported alongside another finding	reported whenever a module may be RENT
struct tag { … } __attribute__((aligned(n)));	reported as writable data	a type definition, not reported
a prototype with a function-pointer parameter, void f(void (*cb)(int));	reported as a pointer variable	a prototype, not reported
static char *days[] = { ("Mon"), ("Tue") };	missed (taken for a function)	reported

Install

mbt is consumed as a git submodule:

git -C mbt fetch --tags
git -C mbt checkout v2.1.3
git add mbt

Then make module-data to see what the check reports for the project. docs/MIGRATION.md describes rent, reus, refr and the check in full.

Changelog

• The module-data check scans every non-system header a source includes, and reports each finding once per module (#153).
• [internal] data is reported whenever any module may be RENT (#153; attributing it to modules through the load map is #152).
• Parser fixes: GNU __attribute__((…)) is ignored when classifying a declaration; only the first parenthesis decides whether a declarator is a function pointer; a declaration with an initializer is never taken for a function head (#153).

mbt 2.1.2

The module-data check's hint now names make module-data MODDATA_ARGS=--all (which passes the project's CFLAGS) instead of a bare script call, and a call without CFLAGS says that it scans the raw sources (#151). Same results as 2.1.1 otherwise.

mbt 2.1.1

Fixes two false positives of 2.1.0's module-data check (#150):

• Files are scanned as cc370 compiles them for MVS: make runs each through cc370 -E with the project's CFLAGS, so host-only branches (#ifndef __MVS__) no longer count.
• static const struct { … } tbl[] = … is read as const.

On a large interpreter project: 25 warnings → the one real case. Each file is preprocessed once and in parallel (~1–3 s on the largest projects).

Bump to this release, not to 2.1.0.

mbt 2.1.0

Load module attributes are declared, not inherited (cc370#100).

• rent, reus, refr on [[module]]/[[test]]. A declared attribute is passed to ld370 in both directions (--rent/--norent …), so the module no longer depends on ld370's default — RENT+REUS until now, neither (IEWL's) in a later cc370 release. norent/noreus still work, with a warning.
• No writable data in a rent = true module: before linking, make scans the C sources (mbtmoddata.py, #91). cc370 keeps writable statics in the module, and a RENT module LINKed by several tasks is one copy — measured on MVS with three server tasks sharing one copy of a module. Writable data in a rent = true module stops the build; a module that is RENT only by ld370's default, or ac = 1, gets a warning.
• Warnings from the configuration step now reach the build log.

What a project should do: declare rent/reus for every module — rent = true only where the check finds no writable data.

Since v2.0.0 also: -Wall -Wextra -Werror by default (#133); relink when a linked library changes (#103); the .d escape after a failed compile (#134); read timeouts as mbt errors (#108); prerelease moves only the owner's tags (#85); libc370 in cc370's second sysroot (#144); the v2 output baseline and behaviour inventory for mbt 3 (docs/v2-baseline.md, docs/v2-behaviours.md).

mbt 2.0.0

First tagged release of mbt — the build system of the mvslovers projects, as it has been on main (f87bf0c).

What it is: the cc370 host build (v2). A project's Makefile is two lines; everything else lives in project.toml. Compile, assemble, link and package on the host with cc370 / as370 / ld370; dependencies resolved against GitHub Releases and pinned in mbt.lock; make test-host and make test-mvs; SMP4 install packages (make dist); make deploy into a DEV library through mvsMF. The [toolchain] section pins libc370 (and cc370) for release builds.

Toolchain: works with cc370 1.0.0 and later. From cc370 1.1.0 the compiler's helper routines live in libcc370rt.a; this release links it before -lc whenever the sysroot has it (#137), which libc370 2.1.0 requires.

Pinning: consumers can now pin the submodule and the reusable workflows to this tag instead of main:

uses: mvslovers/mbt/.github/workflows/build.yml@v2.0.0

Next: the design of mbt 3 — an installable tool instead of a submodule — is under discussion in #136.