mk: Build crates with relative paths to rustc #26252

bluss · 2015-06-12T17:43:42Z

mk: Build crates with relative source file paths

The path we pass to rustc will be visible in panic messages and
backtraces: they will be user visible!

Avoid junk in these paths by passing relative paths to rustc.

For most advanced users, libcore or libstd in the path will be
a clue to the location -- inside our code, not theirs.

Store both the relative path to the source as well as the absolute.
Use the relative path where it matters, compiling the main crates,
instead of changing all of the build process to cope with relative
paths.

Example output after this patch:

$ ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
$ RUST_BACKTRACE=1 ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
stack backtrace:
   1:     0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des
                        at ../src/libstd/sys/unix/backtrace.rs:158
   2:     0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw
                        at ../src/libstd/panicking.rs:58
   3:     0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw
                        at ../src/libstd/rt/unwind/mod.rs:273
   4:     0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw
                        at ../src/libstd/rt/unwind/mod.rs:212
   5:     0x7ff59c1eced7 - rust_begin_unwind
   6:     0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B
                        at ../src/libcore/panicking.rs:64
   7:     0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B
                        at ../src/libcore/panicking.rs:45
   8:     0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829
   9:     0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa
  10:     0x7ff59c1f1c18 - rust_try_inner
  11:     0x7ff59c1f1c05 - rust_try
  12:     0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw
                        at ../src/libstd/rt/unwind/mod.rs:147
                        at ../src/libstd/rt/unwind/mod.rs:130
                        at ../src/libstd/rt/mod.rs:128
  13:     0x7ff59c1e628e - main
  14:     0x7ff59b3f6b44 - __libc_start_main
  15:     0x7ff59c1e6078 - <unknown>
  16:                0x0 - <unknown>

rust-highfive · 2015-06-12T17:43:49Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pcwalton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

bluss · 2015-06-12T17:44:47Z

r? @brson

Full disclosure: I don't know the makefiles.

This compiles, check is still running.

I'm sure it breaks someone's workflow, but it's an important thing and I wanted to get the ball rolling.

alexcrichton · 2015-06-12T17:46:30Z

Unfortunately this will break out-of-tree builds (which is what the bots do) as the $(S) placeholder is used to go up a directory. You can test this out via:

mkdir build
cd build
../configure
make

I think that will give an error about not being able to find src/libcore/lib.rs as it's actually ../src/libcore/lib.rs

That being said, I would love to fix this! I'm just not sure what the best way to do so is :(

bluss · 2015-06-12T17:53:53Z

Thanks for the input, I figured that might be so. I'll try to compute a relative path, just don't know where to put that.

brson · 2015-06-12T20:01:16Z

Might we fix this in rustc itself or possibly the unwinder by truncating the paths? I assume these strings come from dwarf, so modifying them has an implication on how debuggers behave probably.

alexcrichton · 2015-06-12T20:02:24Z

Nah these paths come from file!() (panic messages) which come from the compiler itself (which in turn comes from the command line).

The path we pass to rustc will be visible in panic messages and backtraces: they will be user visible! Avoid junk in these paths by passing relative paths to rustc. For most advanced users, `libcore` or `libstd` in the path will be a clue to the location -- inside our code, not theirs. Store both the relative path to the source as well as the absolute. Use the relative path where it matters, compiling the main crates, instead of changing all of the build process to cope with relative paths. Example output after this patch: ``` $ ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 $ RUST_BACKTRACE=1 ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 stack backtrace: 1: 0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des at ../src/libstd/sys/unix/backtrace.rs:158 2: 0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw at ../src/libstd/panicking.rs:58 3: 0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw at ../src/libstd/rt/unwind/mod.rs:273 4: 0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw at ../src/libstd/rt/unwind/mod.rs:212 5: 0x7ff59c1eced7 - rust_begin_unwind 6: 0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B at ../src/libcore/panicking.rs:64 7: 0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B at ../src/libcore/panicking.rs:45 8: 0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829 9: 0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa 10: 0x7ff59c1f1c18 - rust_try_inner 11: 0x7ff59c1f1c05 - rust_try 12: 0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw at ../src/libstd/rt/unwind/mod.rs:147 at ../src/libstd/rt/unwind/mod.rs:130 at ../src/libstd/rt/mod.rs:128 13: 0x7ff59c1e628e - main 14: 0x7ff59b3f6b44 - __libc_start_main 15: 0x7ff59c1e6078 - <unknown> 16: 0x0 - <unknown> ```

bluss · 2015-06-12T23:52:37Z

Some parts of the build don't cope with a relative path to the source directory (libcompiler_rt.a is the first part that fails), so it's tempting to attempt a hack -- store both the relative and absolute path, use the relative version just where it matters for this issue.

bluss · 2015-06-13T14:05:53Z

If you allow it, I'd send this to the try branch.

pnkfelix · 2015-06-13T15:03:01Z

@bors: try

bors · 2015-06-13T15:03:03Z

⌛ Trying commit 70269cd with merge 82a95fd...

mk: Build crates with relative source file paths The path we pass to rustc will be visible in panic messages and backtraces: they will be user visible! Avoid junk in these paths by passing relative paths to rustc. For most advanced users, `libcore` or `libstd` in the path will be a clue to the location -- inside our code, not theirs. Store both the relative path to the source as well as the absolute. Use the relative path where it matters, compiling the main crates, instead of changing all of the build process to cope with relative paths. Example output after this patch: ``` $ ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 $ RUST_BACKTRACE=1 ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 stack backtrace: 1: 0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des at ../src/libstd/sys/unix/backtrace.rs:158 2: 0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw at ../src/libstd/panicking.rs:58 3: 0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw at ../src/libstd/rt/unwind/mod.rs:273 4: 0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw at ../src/libstd/rt/unwind/mod.rs:212 5: 0x7ff59c1eced7 - rust_begin_unwind 6: 0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B at ../src/libcore/panicking.rs:64 7: 0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B at ../src/libcore/panicking.rs:45 8: 0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829 9: 0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa 10: 0x7ff59c1f1c18 - rust_try_inner 11: 0x7ff59c1f1c05 - rust_try 12: 0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw at ../src/libstd/rt/unwind/mod.rs:147 at ../src/libstd/rt/unwind/mod.rs:130 at ../src/libstd/rt/mod.rs:128 13: 0x7ff59c1e628e - main 14: 0x7ff59b3f6b44 - __libc_start_main 15: 0x7ff59c1e6078 - <unknown> 16: 0x0 - <unknown> ```

bors · 2015-06-13T15:46:26Z

💔 Test failed - try-bsd

bluss · 2015-06-13T20:31:04Z

try looks successful to me, the failure on bsd is probably intermittent, 2/3 builds were successful.

Panics now show paths like ../src/libcore/panicking.rs which is strictly an improvement, the question is if this patch to the makefiles is too ugly for you.

bluss · 2015-06-13T20:32:04Z

@pnkfelix thanks!

alexcrichton · 2015-06-14T04:44:03Z

@bors: r+ 70269cd

Nice!

steveklabnik · 2015-06-14T05:31:29Z

@bors: retry

bors · 2015-06-14T05:31:32Z

⌛ Trying commit 70269cd with merge cbed196...

bors · 2015-06-14T05:41:38Z

💔 Test failed - try-bsd

pnkfelix · 2015-06-14T10:38:53Z

Wait, does bors now require the bsd target in order to merge a PR?

pnkfelix · 2015-06-14T10:39:05Z

@bors retry

bors · 2015-06-14T10:39:07Z

⌛ Trying commit 70269cd with merge b53c0f9...

mk: Build crates with relative source file paths The path we pass to rustc will be visible in panic messages and backtraces: they will be user visible! Avoid junk in these paths by passing relative paths to rustc. For most advanced users, `libcore` or `libstd` in the path will be a clue to the location -- inside our code, not theirs. Store both the relative path to the source as well as the absolute. Use the relative path where it matters, compiling the main crates, instead of changing all of the build process to cope with relative paths. Example output after this patch: ``` $ ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 $ RUST_BACKTRACE=1 ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 stack backtrace: 1: 0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des at ../src/libstd/sys/unix/backtrace.rs:158 2: 0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw at ../src/libstd/panicking.rs:58 3: 0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw at ../src/libstd/rt/unwind/mod.rs:273 4: 0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw at ../src/libstd/rt/unwind/mod.rs:212 5: 0x7ff59c1eced7 - rust_begin_unwind 6: 0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B at ../src/libcore/panicking.rs:64 7: 0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B at ../src/libcore/panicking.rs:45 8: 0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829 9: 0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa 10: 0x7ff59c1f1c18 - rust_try_inner 11: 0x7ff59c1f1c05 - rust_try 12: 0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw at ../src/libstd/rt/unwind/mod.rs:147 at ../src/libstd/rt/unwind/mod.rs:130 at ../src/libstd/rt/mod.rs:128 13: 0x7ff59c1e628e - main 14: 0x7ff59b3f6b44 - __libc_start_main 15: 0x7ff59c1e6078 - <unknown> 16: 0x0 - <unknown> ```

bors · 2015-06-14T10:56:30Z

💔 Test failed - try-bsd

bluss · 2015-06-14T11:14:38Z

Hm, it's stuck to sending it to the try builders

bluss · 2015-06-14T11:17:49Z

@bors: try-

bluss · 2015-06-14T11:18:42Z

@bors: r=alexcrichton

bors · 2015-06-14T11:18:43Z

📌 Commit 70269cd has been approved by alexcrichton

bluss · 2015-06-14T11:20:34Z

@bors: retry

mk: Build crates with relative source file paths The path we pass to rustc will be visible in panic messages and backtraces: they will be user visible! Avoid junk in these paths by passing relative paths to rustc. For most advanced users, `libcore` or `libstd` in the path will be a clue to the location -- inside our code, not theirs. Store both the relative path to the source as well as the absolute. Use the relative path where it matters, compiling the main crates, instead of changing all of the build process to cope with relative paths. Example output after this patch: ``` $ ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 $ RUST_BACKTRACE=1 ./testunwrap thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362 stack backtrace: 1: 0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des at ../src/libstd/sys/unix/backtrace.rs:158 2: 0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw at ../src/libstd/panicking.rs:58 3: 0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw at ../src/libstd/rt/unwind/mod.rs:273 4: 0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw at ../src/libstd/rt/unwind/mod.rs:212 5: 0x7ff59c1eced7 - rust_begin_unwind 6: 0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B at ../src/libcore/panicking.rs:64 7: 0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B at ../src/libcore/panicking.rs:45 8: 0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829 9: 0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa 10: 0x7ff59c1f1c18 - rust_try_inner 11: 0x7ff59c1f1c05 - rust_try 12: 0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw at ../src/libstd/rt/unwind/mod.rs:147 at ../src/libstd/rt/unwind/mod.rs:130 at ../src/libstd/rt/mod.rs:128 13: 0x7ff59c1e628e - main 14: 0x7ff59b3f6b44 - __libc_start_main 15: 0x7ff59c1e6078 - <unknown> 16: 0x0 - <unknown> ```

bors · 2015-06-14T11:20:37Z

⌛ Testing commit 70269cd with merge 606e4b2...

bluss · 2015-06-14T11:27:47Z

I think that should all have been one command to bors, looks like both try and integration build is running. Let's hope this ends well 🎱

bluss · 2015-06-14T11:32:07Z

@Manishearth killed the try builds for me

bors · 2015-06-14T13:44:17Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

In rust-lang#26252 support was added to have prettier paths printed out on failure by not passing the full path to the source file to the compiler, but instead just a small relative path. To preserve this relative path across configurations, the `SREL` variable was used for reconfiguring, but if `SREL` is empty then it will attempt to run the command `configure` which is distinct from running `./configure` (e.g. doesn't run the local script). This commit modifies the `SREL` value to re-run the configure script by setting it to `./` in the case where `SREL` is empty.

In #26252 support was added to have prettier paths printed out on failure by not passing the full path to the source file to the compiler, but instead just a small relative path. To preserve this relative path across configurations, the `SREL` variable was used for reconfiguring, but if `SREL` is empty then it will attempt to run the command `configure` which is distinct from running `./configure` (e.g. doesn't run the local script). This commit modifies the `SREL` value to re-run the configure script by setting it to `./` in the case where `SREL` is empty.

rust-highfive assigned pcwalton Jun 12, 2015

rust-highfive assigned brson and unassigned pcwalton Jun 12, 2015

bluss force-pushed the relative-paths branch from f2b4f95 to 70269cd Compare June 12, 2015 23:50

bors merged commit 70269cd into rust-lang:master Jun 14, 2015

bluss deleted the relative-paths branch June 14, 2015 14:07

alexcrichton mentioned this pull request Jun 18, 2015

mk: Fix reconfiguring top-level ./configure #26381

Merged

mk: Build crates with relative paths to rustc #26252

mk: Build crates with relative paths to rustc #26252

Uh oh!

Conversation

bluss commented Jun 12, 2015

Uh oh!

rust-highfive commented Jun 12, 2015

Uh oh!

bluss commented Jun 12, 2015

Uh oh!

alexcrichton commented Jun 12, 2015

Uh oh!

bluss commented Jun 12, 2015

Uh oh!

brson commented Jun 12, 2015

Uh oh!

alexcrichton commented Jun 12, 2015

Uh oh!

bluss commented Jun 12, 2015

Uh oh!

bluss commented Jun 13, 2015

Uh oh!

pnkfelix commented Jun 13, 2015

Uh oh!

bors commented Jun 13, 2015

Uh oh!

bors commented Jun 13, 2015

Uh oh!

bluss commented Jun 13, 2015

Uh oh!

bluss commented Jun 13, 2015

Uh oh!

alexcrichton commented Jun 14, 2015

Uh oh!

steveklabnik commented Jun 14, 2015

Uh oh!

bors commented Jun 14, 2015

Uh oh!

bors commented Jun 14, 2015

Uh oh!

pnkfelix commented Jun 14, 2015

Uh oh!

pnkfelix commented Jun 14, 2015

Uh oh!

bors commented Jun 14, 2015

Uh oh!

bors commented Jun 14, 2015

Uh oh!

bluss commented Jun 14, 2015

Uh oh!

bluss commented Jun 14, 2015

Uh oh!

bluss commented Jun 14, 2015

Uh oh!

bors commented Jun 14, 2015

Uh oh!

bluss commented Jun 14, 2015

Uh oh!

bors commented Jun 14, 2015

Uh oh!

bluss commented Jun 14, 2015

Uh oh!

bluss commented Jun 14, 2015

Uh oh!

bors commented Jun 14, 2015

Uh oh!

Uh oh!