rustc --dep-info has started using absolute paths in the output

[lilyball]

When using rustc --dep-info lib.d lib.rs the resulting lib.d file has started including absolute paths for the resulting library, instead of the expected relative paths.

Previously:

> rustc --dep-info lib.d lib.s
> cat lib.d
libirc-943b2bb5-0.1.rlib: lib.rs conn.rs handlers.rs

Now:

> rustc --dep-info lib.d lib.rs
> cat lib.d
/Users/kevin/Dev/rust/rust-irclib/libirc-943b2bb5-0.1.rlib: lib.rs conn.rs handlers.rs

[lilyball]

Adding --out-dir . restores the relative output, which is bizarre because . is the default out dir.

[lilyball]

I believe this was introduced in 6e7968b

[alexcrichton]

I believe the problem is that if you don't specify --out-dir it uses os::getcwd() as the output directory. It should probably just use Path::new(".") as the output directory.

[alexcrichton]

The relevant code is here: https://github.com/mozilla/rust/blob/master/src/librustc/driver/driver.rs#L1088-L1091

[lilyball]

I'm doing a build right now that restores the old logic of

            let dirpath = match *odir {
                Some(ref d) => d.clone(),
                None => match *input {
                    StrInput(_) => os::getcwd(),
                    FileInput(ref ifile) => ifile.dir_path()
                }
            };

That said, I think I like Path::new(".") better, because that matches my expectation of --out-dir defaulting to ..

[alexcrichton]

That logic will restore the correct --out-dir behavior, but it will not have the correct build behavior. We changed it to output by default to the current directory, not to the directory holding the source file (which is what the old logic did).

[lilyball]

Ahh, I see. In that case, Path::new(".") makes more sense.