Error: environment variable `OUT_DIR` not defined

help
1

I'm building a library and a crate together, with the binary depending on the library. My directory structure looks like this:

.
├── build.rs
├── Cargo.lock
├── Cargo.toml
├── code_of_conduct.md
├── CONTRIBUTING.md
├── disk-nvme.img
├── disk-sata.img
├── docs
│   ├── book
│   ├── book.toml
│   └── src
│       ├── chapter_1.md
│       └── SUMMARY.md
├── libk
│   ├── Cargo.lock
│   ├── Cargo.toml
│   └── src
│       ├── acpi.rs
│       ├── disk.rs
│       ├── gdt.rs
│       ├── interrupts.rs
│       ├── lib.rs
│       ├── memory.rs
│       ├── pci.rs
│       ├── rtc.rs
│       ├── task
│       │   ├── cooperative
│       │   │   ├── executor.rs
│       │   │   └── mod.rs
│       │   └── mod.rs
│       └── timer.rs
├── LICENSE
├── Makefile.toml
├── OVMF.fd
├── qemu2.log
├── qemu.log
├── README.md
├── src
│   ├── graphics.rs
│   └── main.rs
└── x86_64-kernel-none.json

I'm using cargo make to build the project. Part of my build process is to run cargo check and cargo clippy. However, when running cargo check, Rust complains that the OUT_DIR environment variable is not defined, which is needed for this source code:

include!(concat!(env!("OUT_DIR"), "/pciids.rs"));

This makes absolutely no sense to me, since the build script runs without any issues. Can somebody enlighten me as to why this is happening?

2

Okay, so I've solved the first problem but I'm now getting "can't find crate for std". This is despite the fact that any use of std is in my build script, only, and not anywhere else. I think Cargo is building my build script with no_std... I can't remember how to solve this but I know I've suffered this before. It only happens with my library target though, not my main binary target, at least from what I can see. I'm surprised this bug is still even a thing. Its choking on the log target, but in both Cargo.toml files, I have:

[dependencies.log]
default-features =false
version = "0.4.14"

Edit: I'm also building using a custom target profile, but Cargo still shouldn't be building any build scripts with that target profile but should be building them using the native one.

3

The OUT_DIR can be defined in the makefile.toml

[env]
OUT_DIR = "somedir"

and for the missing std, i see many other threads about it.
for example:

4

Regarding the OUT_DIR, know that —outside of cargo make-specific stuff— the env var is only present if you have a build.rs script. In your case, the libk/ crate does not seem to have one.

Regarding the std stuff, are you using resolver = "2"? There are bugs regarding the default "feature resolver" which make the features for build.rs scripts & procedural macros (and other target-specific deps and whatnot) to be unified all together, which the resolver = "2" solves.

2 Likes
5

Thanks, I had forgotten about that key. Adding that to both crates is now producing this weird compiler error with extprim that I didn't encounter before:

   Compiling extprim v1.7.1
error[E0557]: feature has been removed
  --> /home/ethin/.cargo/registry/src/github.com-1ecc6299db9ec823/extprim-1.7.1/src/lib.rs:58:81
   |
58 | #![cfg_attr(extprim_channel="unstable", feature(llvm_asm, test, specialization, const_fn))]
   |                                                                                  8 caret characters feature has been removed
   |
   = note: split into finer-grained feature gates

Apparently, the syntex_syntax crate requires it. That crate, in turn, is needed by rustfmt. Is the "rustfmt" crate on crates.io the one that the rustfmt tool uses, or do I have to use another registry?

6

I don't believe rustfmt is published to crates.io any more because it uses rustc's internal APIs directly. So rustup distributes it alongside the version of rustc it is built for.

7

The page you've linked to tells to use https://crates.io/crates/rustfmt-nightly, is this what you want?

8

i see the nightly at: https://crates.io/crates/rustfmt-nightly
Also their github readme points to it (via badge).
I agree it's a bit confusing.

9

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.