Don't emit rerun-if-changed on llvm-config if using system LLVM

The code was broken because it printed "llvm-config" instead of the
absolute path to the llvm-config executable, causing Cargo to always
rebuild librustc_llvm if using system LLVM.

Also, it's not the build system's job to rebuild when a system library
changes, so we simply don't emit "rerun-if-changed" if a path to LLVM
was not explicitly provided.

Author: luca-barbieri

src/librustc_llvm/build.rs

@@ -24,18 +24,28 @@ fn main() {
     build_helper::restore_library_path();
 
     let target = env::var("TARGET").expect("TARGET was not set");
-    let llvm_config = env::var_os("LLVM_CONFIG").map(PathBuf::from).unwrap_or_else(|| {
-        if let Some(dir) = env::var_os("CARGO_TARGET_DIR").map(PathBuf::from) {
-            let to_test =
-                dir.parent().unwrap().parent().unwrap().join(&target).join("llvm/bin/llvm-config");
-            if Command::new(&to_test).output().is_ok() {
-                return to_test;
+    let llvm_config =
+        env::var_os("LLVM_CONFIG").map(|x| Some(PathBuf::from(x))).unwrap_or_else(|| {
+            if let Some(dir) = env::var_os("CARGO_TARGET_DIR").map(PathBuf::from) {
+                let to_test = dir
+                    .parent()
+                    .unwrap()
+                    .parent()
+                    .unwrap()
+                    .join(&target)
+                    .join("llvm/bin/llvm-config");
+                if Command::new(&to_test).output().is_ok() {
+                    return Some(to_test);
+                }
             }
-        }
-        PathBuf::from("llvm-config")
-    });
+            None
+        });
+
+    if let Some(llvm_config) = &llvm_config {
+        println!("cargo:rerun-if-changed={}", llvm_config.display());
+    }
+    let llvm_config = llvm_config.unwrap_or_else(|| PathBuf::from("llvm-config"));
 
-    println!("cargo:rerun-if-changed={}", llvm_config.display());
     println!("cargo:rerun-if-env-changed=LLVM_CONFIG");
 
     // Test whether we're cross-compiling LLVM. This is a pretty rare case