comphead commented on code in PR #7614:
URL: https://github.com/apache/datafusion-comet/pull/7614#discussion_r4565847371
##########
native/core/build.rs:
##########
@@ -18,6 +18,14 @@
use std::env;
use std::path::Path;
+fn target_profile_dir(out_dir: &Path) -> &Path {
+ out_dir
+ .ancestors()
+ .find(|path| path.file_name().is_some_and(|name| name == "build"))
+ .and_then(Path::parent)
+ .expect("OUT_DIR must be inside Cargo's profile build directory")
+}
Review Comment:
This finds the profile directory of the build dir, which is the target dir
only by default. With `build.build-dir` set (or `CARGO_BUILD_BUILD_DIR`),
`OUT_DIR` moves there and the cdylib stays in `target/<profile>`. With Cargo
1.99.1 and `CARGO_BUILD_BUILD_DIR=/tmp/bdir`, a probe crate got
`OUT_DIR=/tmp/bdir/debug/build/odprobe-<hash>/out`, and its cdylib went to
`target/debug`, so this returns `/tmp/bdir/debug`. The old `nth(3)` had the
same gap, so it does not block this PR. Could the comment where
`COMET_TEST_UDFS_LIB` is set say that it assumes the default build dir, so the
next failure is easier to place? I have not tried it with 1.100.
--
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]
