Rust should support a no extra attribute and flag.

[mstewartgallus]

Rust should support a no extra attribute and flag. This would be useful for me so I could:

• compile my own hacked version of extra like rustc rust/src/libextra/extra.rs --output-dir .
• compile a regressing benchmark like rustc -L . -Z no-extra rust/src/test/bench/msgsend-mutex-arcs.rs -o mutex-bench
• and then run the benchmark file like ./mutex-bench

This would greatly speed up time hunting for the regression in mutex performance for my pull request #7701 .

[alexcrichton]

I think that this should all work today anyway. Rust knows nothing about an "extra" library, so there's no need to add extra flags for it. It only so happens that the supplement of libstd is libextra. Sadly you can't quite accomplish what you wanted to do because you'd get conflicting messages about duplicate libextra files.

On the other hand, you could always modify extra.rs to have the name be something like extra2 and then have extern mod extra2 in your source file.

[alexcrichton]

Basically the steps to achieve what you want sound like they can be accomplished with:

1. Edit link(name=...) in src/libextra/extra.rs
2. Compile to the current directory.
3. Use extern mod extra2 or whatever name you used to link to it
4. Compile code with -L .

Now those steps may be a bit complicated, so in my opinion the issue should be more about simplifying them possibly?

[mstewartgallus]

Yes, the problem is the existing workaround is too complex. My idea about the flags is just one specific suggestion.

I think I should clarify the issue. The main problem is that the process of developing, and managing alternate versions of existing libraries is too complicated. I know the Haskell cabal package manager has a similar problem, and that people have various hacks so that they can switch between, and use separate Haskell build environments. Perhaps we can steal a good solution from there?

Also, this might be more a rustpkg problem than a rustc problem. Perhaps when rustpkg is more mature the process of automatically pulling in the extra directory could be pulled up a level of abstraction to rustpkg instead of rustc?

[Aatch]

This is a build system problem. As @alexcrichton said, rust knows nothing about libextra. The only real issue I can see here is that if rustc can find multiple, matching crates then it bails out.

A possible solution would be making paths given on the command line take priority, so if multiple matching crates are found, it picks the highest priority one. It would still bail out if there are multiple "highest" libs though.

[huonw]

(@Aatch to be pedantic, it actually does, front::test inserts it automagically for --test.)

[mstewartgallus]

Okay, here's my idea of how this could be solved by moving getting the extra library up a level to rustpkg. By default when RUST_PATH is unset, the location of the extra library is included in RUST_PATH. But one could set RUST_PATH to a different value, and point to a different extra library. Under this scheme rustc itself would know nothing about the extra library.

[thestinger]

Closing in favour of #8784 which is as far as I know the unofficial official plan.