Thanks for the suggestion - this gets me close! My current problem seems to be that the modification time isn't correctly picked up (!?). I'm using the code below to get the modified times (std and filetime crate have the same behaviour AFAICT):
// fn get_modified_time<T: AsRef<Path>>(file: &T) -> SystemTime {
// metadata(file).unwrap().modified().unwrap()
// }
fn get_modified_time<T: AsRef<Path>>(file: &T) -> FileTime {
FileTime::from_last_modification_time(&metadata(file).unwrap())
}
Here's some compilation output, with cargo warnings littered around to help me debug:
CXX=/opt/cuda/bin/g++ cargo build --release
warning: /home/chj/Software/personal/mwa_hyperdrive/target/release/build/mwa_hyperdrive-d594a365b0d72114/out/libhyperdrive_cu.a
warning: cuda_library_mod_time: FileTime { seconds: 1598410021, nanos: 636274949 }
warning: src_cuda/vis_gen.cu FileTime { seconds: 1598410797, nanos: 634500914 }
warning: FileTime { seconds: 1598410021, nanos: 636274949 } FileTime { seconds: 1598410797, nanos: 634500914 }
warning: compiling cuda!
Finished release [optimized] target(s) in 0.05s
Because the modification times aren't accurate, sometimes, I will always be "compiling cuda", or not. Is this related to filesystem journaling, or something? If I touch or modify the CUDA file, these mtimes don't update, either.
Aside from all this, it seems that the build-time variables aren't being generated for every invokation of cargo build
, even after adding a recursive function:
fn rerun_directory<T: AsRef<Path> + ?Sized>(dir: &T) {
println!("cargo:rerun-if-changed={}", dir.as_ref().to_str().unwrap());
// Find any other directories in this one.
for entry in read_dir(dir).unwrap() {
let entry = entry.expect("Couldn't access file in src directory");
let path = entry.path().to_path_buf();
// Skip this entry if it isn't a directory.
if !path.is_dir() {
continue;
}
rerun_directory(&path);
}
}
fn main() {
rerun_directory("src");
rerun_directory("src_cuda");
// ...
For a seemingly small thing, this is quite bothersome! Any ideas? I'd rather not depend on make
, but I guess that's looking good right now... I'm not worried about cross-platform compatibility, as this code is intended for linux-only desktops and supercomputers.