Skip to content

cli/manifest/build: tt package build and fetch#1323

Open
bigbes wants to merge 1 commit into
v3from
bigbes/tntp-8611-tt-build
Open

cli/manifest/build: tt package build and fetch#1323
bigbes wants to merge 1 commit into
v3from
bigbes/tntp-8611-tt-build

Conversation

@bigbes

@bigbes bigbes commented Jul 16, 2026

Copy link
Copy Markdown
Collaborator

Orchestrate the full package build cycle, stitching the earlier waves (model, version, resolver, rocks adapter, component backends) into one pass that materializes the project's .rocks/ tree. In order: derive the version, run pre_build, gate the lock (resolve and rewrite unless --locked), materialize the pinned closure, run each component's build backend, lay component files out under their install namespace, generate version.lua, then run post_build. tt package fetch is the same materialization step in isolation: strictly from the lock, no resolve and no backends.

Include/exclude uses go-git's gitignore matcher with the spec defaults (always-on hazard excludes plus the component's own patterns); .lua land under share/tarantool// and .so under lib/tarantool//, flat when the namespace is empty. version.lua is generated under the package name and a component shipping one there is a collision (exit 1); a stale lock under --locked is exit 1; a component build backend failure is exit 2. Lifecycle hooks reuse the backend machinery through a new RunHook under the reduced contract (no TT_OUTPUT_DIR/TT_COMPONENT_NAME).

Filtering, layout, version.lua, product selection, the lock gate and materialization are unit-tested on fixtures; the live cc/Tarantool build of my-app is gated behind the integration tag.

Part of TNTP-8611

@bigbes
bigbes force-pushed the bigbes/tntp-8232-native-modules branch from b12164e to ee008a7 Compare July 17, 2026 08:38
@bigbes
bigbes force-pushed the bigbes/tntp-8611-tt-build branch from 17bf195 to c9e5a72 Compare July 17, 2026 08:38
@bigbes
bigbes marked this pull request as ready for review July 17, 2026 08:38
Base automatically changed from bigbes/tntp-8232-native-modules to v3 July 17, 2026 11:01
Orchestrate the full package build cycle, stitching the earlier waves
(model, version, resolver, rocks adapter, component backends) into one
pass that materializes the project's .rocks/ tree. In order: derive the
version, run pre_build, gate the lock (resolve and rewrite unless
--locked), materialize the pinned closure, run each component's build
backend, lay component files out under their install namespace, generate
version.lua, then run post_build. tt package fetch is the same
materialization step in isolation: strictly from the lock, no resolve
and no backends.

Include/exclude uses go-git's gitignore matcher with the spec defaults
(always-on hazard excludes plus the component's own patterns); .lua land
under share/tarantool/<ns>/ and .so under lib/tarantool/<ns>/, flat when
the namespace is empty. version.lua is generated under the package name
and a component shipping one there is a collision (exit 1); a stale lock
under --locked is exit 1; a component build backend failure is exit 2.
Lifecycle hooks reuse the backend machinery through a new RunHook under
the reduced contract (no TT_OUTPUT_DIR/TT_COMPONENT_NAME).

Filtering, layout, version.lua, product selection, the lock gate and
materialization are unit-tested on fixtures; the live cc/Tarantool build
of my-app is gated behind the integration tag.

Part of TNTP-8611
@bigbes
bigbes force-pushed the bigbes/tntp-8611-tt-build branch from c9e5a72 to 615addf Compare July 17, 2026 13:43
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.

3 participants