CmdBuild / make: Accommodate projects that only have a Makefile #112

Merged
Jan Lindemann merged 2 commits from jan/feature/20260919-cmdbuild-make-accommodate-projects-that-only-have-a-makefile into master 2026-09-19 17:44:54 +02:00 AGit

Legacy projects that only have a Makefile (no VERSION, no make/project.conf) are breaking the workspace build: subdirectories include make/disabled.mk, which the 2025-11-14 make purge dropped, and working around that, projects build still raises an unmet dependency, because the dependency walk requires package installation proofs that such a project can never have. This PR restores disabled.mk and lets the build accommodate such projects: requested modules without package proofs but with a workspace directory holding a Makefile are appended to the build order as dependency-less leaves and built with a plain make. The walk and App.is_installed() stay strict for every other projects command.

make/disabled.mk: Re-add file for legacy projects

The Remove everything non-essential for make clean all commit (bc883deed) dropped disabled.mk, judged non-essential from the jw-pkg tree's own perspective. Legacy projects still include it, though: their Makefiles use it to replace a directory build with no-op targets that report the target as disabled. Without the file, make fails in such projects in any workspace that mounts a current jw-pkg.

Re-add it verbatim. The post-purge re-adds dummy.mk and dummy-topdir.mk cover the current-style stubs; disabled.mk covers the legacy includes.

CmdBuild.run(): Build projects that only have a Makefile

A workspace project directory that has a Makefile but no package proofs - no project.conf, no VERSION - is buildable with a plain make, yet the build fails on it: calculate_order() walks the requested modules, and the walk in App.__get_project_refs() raises an unmet dependency, because the installation state of such a project is unprovable.

The walk has to stay strict: its proofs are package proofs, and loosening App.is_installed() would weaken the unmet dependency detection for every get_project_refs() caller.

This commit therefore keeps the tolerance in the build: before calculating the order, run() partitions the requested modules. A module that is not installed in any flavour but resolves to a workspace directory with a Makefile is appended to the build order as a dependency-less leaf and built with a plain make; modules without any directory at all still raise the unmet dependency error. A jw dependency declared in a project.conf on such a project still raises, which is correct: it is a declared dependency on a package that does not exist.

Legacy projects that only have a Makefile (no `VERSION`, no `make/project.conf`) are breaking the workspace build: subdirectories include `make/disabled.mk`, which the 2025-11-14 make purge dropped, and working around that, `projects build` still raises an unmet dependency, because the dependency walk requires package installation proofs that such a project can never have. This PR restores `disabled.mk` and lets the build accommodate such projects: requested modules without package proofs but with a workspace directory holding a Makefile are appended to the build order as dependency-less leaves and built with a plain make. The walk and `App.is_installed()` stay strict for every other projects command. #### make/disabled.mk: Re-add file for legacy projects The `Remove everything non-essential for make clean all` commit (`bc883deed`) dropped `disabled.mk`, judged non-essential from the `jw-pkg` tree's own perspective. Legacy projects still include it, though: their Makefiles use it to replace a directory build with no-op targets that report the target as disabled. Without the file, make fails in such projects in any workspace that mounts a current `jw-pkg`. Re-add it verbatim. The post-purge re-adds `dummy.mk` and `dummy-topdir.mk` cover the current-style stubs; `disabled.mk` covers the legacy includes. #### CmdBuild.run(): Build projects that only have a Makefile A workspace project directory that has a Makefile but no package proofs - no `project.conf`, no `VERSION` - is buildable with a plain make, yet the build fails on it: `calculate_order()` walks the requested modules, and the walk in `App.__get_project_refs()` raises an unmet dependency, because the installation state of such a project is unprovable. The walk has to stay strict: its proofs are package proofs, and loosening `App.is_installed()` would weaken the unmet dependency detection for every `get_project_refs()` caller. This commit therefore keeps the tolerance in the build: before calculating the order, `run()` partitions the requested modules. A module that is not installed in any flavour but resolves to a workspace directory with a Makefile is appended to the build order as a dependency-less leaf and built with a plain make; modules without any directory at all still raise the unmet dependency error. A jw dependency declared in a `project.conf` on such a project still raises, which is correct: it is a declared dependency on a package that does not exist.
The "Remove everything non-essential for make clean all" commit (bc883deed)
dropped disabled.mk, judged non-essential from the jw-pkg tree's own
perspective. Legacy projects still include it, though: their Makefiles use
it to replace a directory build with no-op targets that report the target
as disabled. Without the file, make fails in such projects in any workspace
that mounts a current jw-pkg.

Re-add it verbatim. The post-purge re-adds dummy.mk and dummy-topdir.mk
cover the current-style stubs; disabled.mk covers the legacy includes.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.85.1
Signed-off-by: Jan Lindemann <jan@janware.com>
CmdBuild.run(): Build projects that only have a Makefile
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 5m31s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m42s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 5m7s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m25s
CI / Packaging test (push) Successful in 0s
9961d4b5f4
A workspace project directory that has a Makefile but no package proofs -
no project.conf, no VERSION - is buildable with a plain make, yet the build
fails on it: calculate_order() walks the requested modules, and the walk in
App.__get_project_refs() raises an unmet dependency, because the
installation state of such a project is unprovable.  The walk has to stay
strict: its proofs are package proofs, and loosening App.is_installed()
would weaken the unmet dependency detection for every get_project_refs()
caller.

This commit therefore keeps the tolerance in the build: before calculating
the order, run() partitions the requested modules. A module that is not
installed in any flavour but resolves to a workspace directory with a
Makefile is appended to the build order as a dependency-less leaf and built
with a plain make; modules without any directory at all still raise the
unmet dependency error. A jw dependency declared in a project.conf on such
a project still raises, which is correct: it is a declared dependency on a
package that does not exist.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.85.1
Signed-off-by: Jan Lindemann <jan@janware.com>
Jan Lindemann scheduled this pull request to auto merge when all checks succeed 2026-09-19 17:34:38 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
janware/jw-pkg!112
No description provided.