pdulvp.fr

buildCommand for 'prel build', releaseBuildCommand for the release has been fixed.

See more details at : https://github.com/pdulvp/prel/issues/10

releaseBuildCommand stays the release's own, run by prel release

which is how it gets tried before a release depends on it

  • neither key stands in for the other: an unset key means there is no build to

run, and the output names the key that ran rather than just saying "build"

  • 0.2.3 called the release build buildCommand, so a config written then is

told where a release would otherwise build nothing - on the build: line of
the release plan and under an artifact pattern that matched no file - rather
than warned about in prel config, where both keys are now valid

buildCommand for 'prel build', releaseBuildCommand for 'prel release'

<sub>2026-10-22-2141-two-build-commands.md — 2026-10-22 22:05</sub>

Goal

There is one build command in prel.config.json and two things to build. The
ordinary build of a project - the one run while working on it - is not the
build that makes the files a release carries, and prel build running the
release build left a project with no way to say what its ordinary build is.

Two keys, each read by the command it is named for:

{
  "buildCommand": "make",
  "releaseBuildCommand": "packaging/build-deb.sh ${version}"
}

prel build runs buildCommand. prel release runs releaseBuildCommand.
prel build --release runs releaseBuildCommand without releasing anything,
which is what prel build was added for: trying the release build before a
release depends on it.

Decisions

  • No fallback either way. Each command reads its own key, and a key not set

means there is no build to run - said plainly with the key to set, exit 0,
as prel build says it today. A release never reaches for buildCommand
and prel build never reaches for releaseBuildCommand unless --release
asks it to.

  • buildCommand becomes a live key again rather than staying a renamed one:

_PREL_CONFIG_RENAMED_OLD/NEW and the warning over them go, since the name
is read once more - for a different build. The prel.buildCommand git key
keeps pointing at releaseBuildCommand, which is the build it configured.

  • 0.2.3 shipped buildCommand as the release build, so a config written then

now names the ordinary build and a release would build nothing. Not a config
warning - buildCommand with no releaseBuildCommand is a perfectly good
config for a project that releases a tag and no files - but said where it
changes what happens: the release plan prints `build: nothing,
releaseBuildCommand not set, and prel release artifacts` names the key
under a pattern that matched nothing.

  • --release rather than a second command: everything else about prel build
  • the version, the tag, the directory, the artifacts report, -n - is the

same, and only the key read differs.

uses, so buildCommand: and releaseBuildCommand: both fit and the output
says which of the two was run.

repository root, $version, $tag), used by both modes and by the build
step of prel release.

Steps

releaseBuildCommand, the renamed-key machinery and its warning out,
the config usage key list and sample

--release selecting _rel_build_command, the key-named header lines,
the messages that name the key, and the usage text

plan line where buildCommand is set instead, the same hint in
_rel_check_artifacts, and the release usage text on the two keys

prel build section on both modes, the release-artifacts section, the
.deb section (prel build --release in a clone), the configuration-files
list, and the 0.2.3 note on what buildCommand means now

version, a bad version; prel build --release in this repository
(builds the .deb), --release -n, and with no releaseBuildCommand

  • [x] test: prel config on both keys and on a config setting only

buildCommand; prel release 0.2.4 -n with and without
releaseBuildCommand; prel release artifacts; build.sh and
release.sh run directly

archive this file

<sub>Filed by prel from the completed plans at commit time.</sub>