sunchao commented on code in PR #5344:
URL: https://github.com/apache/datafusion-comet/pull/5344#discussion_r3779986393


##########
Makefile:
##########
@@ -51,18 +51,18 @@ format:
 
 # build native libs for amd64 architecture Linux/MacOS on a Linux/amd64 
machine/container
 core-amd64-libs:
-       cd native && RUSTFLAGS="-Ctarget-cpu=x86-64-v3" cargo build -j 2 
--release $(FEATURES_ARG)
+       cd native && RUSTFLAGS="-Ctarget-cpu=x86-64-v3" cargo build --release 
$(FEATURES_ARG)

Review Comment:
   [P2] Could we forward CARGO_BUILD_JOBS into both release-builder containers 
before removing this cap? The documented release workflow invokes 
dev/release/build-release-comet.sh, whose two docker run commands impose 
--memory 24g and --cpus 6 but do not pass CARGO_BUILD_JOBS or mount the host 
Cargo configuration. Their entrypoint then runs these Makefile targets, so 
setting CARGO_BUILD_JOBS=2 on the host does not reach Cargo inside either 
container. As a result, the actual release build loses its existing two-job 
limit and cannot use the override described in this PR, while the release 
profile enables debug information and ThinLTO. The green native CI jobs call 
cargo build --profile ci directly, so they do not exercise this Dockerized 
release path. Please propagate the variable through both docker run 
invocations, ideally with an overridable default of 2.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to