Gdext-dependent crate fails during Github Actions CI build

[StatisMike]

I've encountered problems during building a gdext-dependent crate (gd-props) on GitHub Actions workflow, as shown in the below excerpt from the run:

Compiling godot-core v0.1.0 (https://github.com/godot-rust/gdext?branch=master#3b7c6746)
   Compiling serde_derive v1.0.197
error: failed to run custom build command for `godot-core v0.1.0 (https://github.com/godot-rust/gdext?branch=master#3b7c6746)`
Caused by:
  process didn't exit successfully: `/home/runner/work/gd-props/gd-props/target/debug/build/godot-core-225c2f5[74](https://github.com/StatisMike/gd-props/actions/runs/7977640547/job/21780962982#step:8:75)eea24b0/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at /home/runner/.cargo/git/checkouts/gdext-76630c89719e160c/3b7c674/godot-core/build.rs:16:62:
  failed to delete dir: Directory not empty (os error 39)
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Referenced line points at std::fs::remove_dir_all() from the build script:

gdext/godot-core/build.rs

Lines 15 to 17 in 3b7c674

	if gen_path.exists() {
	std::fs::remove_dir_all(gen_path).unwrap_or_else(|e| panic!("failed to delete dir: {e}"));
	}

While trying to come up with a solution (and reason for why it keeps happening), I've come across still open Rust issue from 2015. Although the linked issue seems to be specific about Windows as OS where it keeps happening, it also keeps happening during my CI workflow on ubuntu-latest

For the Rust toolchain, I'm using (fairly popular I think): dtolnay/rust-toolchain@stable.

The simplest solution I came up with for this problem is recovery from error, waiting for a little and retrying with dir removal operation which seems to be consistently fixing the issue on the godot-core build script is just waiting for 10 milliseconds, and retrying up to 5 times. After fixing this issue on my fork once the same problem happened during the godot-ffi build, which uses the same function, though a level deeper:

gdext/godot-bindings/src/lib.rs

Lines 129 to 134 in 3b7c674

	pub fn clear_dir(dir: &Path, watch: &mut StopWatch) {
	if dir.exists() {
	std::fs::remove_dir_all(dir).unwrap_or_else(|e| panic!("failed to delete dir: {e}"));
	watch.record("delete_gen_dir");
	}
	std::fs::create_dir_all(dir).unwrap_or_else(|e| panic!("failed to create dir: {e}"));

Problem on godot-ffi happened only once after patching up the godot-core build, and I think I've unfortunately lost the log.

I will open a PR shortly for the proposed wait-and-retry strategy unless someone has a better solution (as I am aware that this is a little brute force). As we would want for gdext to isolate the codegen into a separate crate, which is currently unfortunately blocked by symbol discoverability problems in some popular IDEs, I wouldn't want to delve too deep into this issue and rewrite the std library functionality.