Running configuration tests from build.rs

since different platforms have subtle differences (libc in this case) i want to run configuration tests from build.rs.

That is:
For each 'feature' defined in Cargo.toml check if there is a conf_test/feature.rs, if so then try to compile (which may already fail) and run it. When both succeeds then enable that feature.

So far so good, I got that mostly working. What is lacking is that haven't found a way how to get the library path that cargo passes to build.rs with the --extern flag. Is there any way to access that or get cargo to tell me about the libraries used and resolve the paths?

UPDATE:
'cargo rustc --message-format json -- --emit metadata' would give me the the data, but calling cargo from cargo blocks, possibly because it waits for a lock in the build directory.

UPDATE2:
'cargo rustc --target-dir ...' fixed the locking problem. I hope that solved all problems.

autocfg - Rust might or might not help to automate some of these. It's geared towards rust's own features, but I think could be used to, eg, test the size_of cint and such.

Out of curiosity, which differences exactly do you want to detect this way?

currently if some (O_PATH, O_DIRECTORY, O_SEARCH) flags are supported in libc::open() and later as well availability of some non-standard functions like statx() renameat2(). more to come.

Note that the build.rs runs on the host machine which can be different from the target machine. Rust supports cross compile anyway.

The libs I want to test against are the ones used for the build, It may become a problem when these tests cant be executed, but I'll support fallbacks for manual overrides. Anyway i may just offer testing for successful compilation without running it. Will consider that in future.

FYI: first step was to abstract the OS-capabilities into cargo features. By that the configuration is done in Cargo.toml and not littered all over the code.

https://github.com/tailhook/openat/pull/41/commits/6b4d359a8a56209378e4bc5b0288a4d5b583979a

Next step would be this 'conf_tests/' thing because maintaining lists of supported features per OS would be a cumbersome, failure-prone task (At least I don't even know what features all the OS'es support do or do not support) besides the featureset may be even changing with new kernels/libc versions.

Let me conclude this discussion with:

:smiley:

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.