Map source absolute paths to OUT_DIR as relative. #684
Conversation
dot-asm
force-pushed
the
compiling-absolute-paths
branch
from
5970ce5
to
5127304
Compare
|
This method can still cause multiple distinct paths to be mapped to the same object file. For example, all these source files will be mapped to the same object file: A different option could be to include a hash of the source path in the object name. That avoids clashes without producing very long file paths. |
|
Well, arguably suggested scenario is unlikely to be a common case, but I've added unique prefix based on absolute path for maintainers to consider :-) |
|
I'd remove the path grafting entirely now. I'd even consider doing the same for relative paths and dump all object files in one directory. Although I guess it's nice to mimic the directory structure for relative paths. |
Even for relative paths? The original idea was to be as conservative as possible. I mean not changing the way it currently works in the most common case of relative paths. As for absolute paths, yeah, I've thought of "flattening" and reckoned that keeping traces of the directory structure could be helpful for trouble-shooting purposes. But sure, it's definitely a viable option. For both relative and absolute paths. Nobody traverses the object files' destination directories anyway... |
On the other hand, one can totally say that "flattening" would actually be more a conservative approach, because that's how the absolute paths are treated now. Fair enough, I'll remove the grafting for absolute paths and let maintainers choose [or express their preferences]... |
|
Note for maintainers. There are three suggestions to consider, one per commit. First one attempts to graft subdirectories of absolute source files' paths to output directory. The second one prefixes object files with source directories' hashes. And the third one removes grafting. There is also suggestion to use hashes as prefixes even with relative paths. |
dot-asm
force-pushed
the
compiling-absolute-paths
branch
from
1bf8899
to
e151b9e
Compare
Could you clarify the course of further actions for me here. I mean should I remove all commits but the fist here, or do you simply cherry-pick it yourself? |
If a source file was specified by absolute path, then the corresponding object file was placed into OUT_DIR. This posed a problem if multiple files with the same base name were specified by absolute paths. Fixes rust-lang#683.
dot-asm
force-pushed
the
compiling-absolute-paths
branch
from
e151b9e
to
36137ae
Compare
|
Sorry, that wasn't about the commit structure. I just forgot to merge |
Since rust-lang#684 was merged, it is impossible for `obj` to not start with dst - if `obj` is absolute or contains `../` in its Path, then the path will be hashed, and the file will still be placed under dst. As such, this obj.starts_with(&dst) check is always true.
Since rust-lang#684 was merged, it is impossible for `obj` to not start with dst - if `obj` is absolute or contains `../` in its Path, then the path will be hashed, and the file will still be placed under dst. As such, this obj.starts_with(&dst) check is always true.
* Add new compile_intermediates function. This new function can be used to just compile the files to a bunch of .o files. * Pre-allocate objects vec in objects_from_files * Remove some dead code in objects_from_file Since #684 was merged, it is impossible for `obj` to not start with dst - if `obj` is absolute or contains `../` in its Path, then the path will be hashed, and the file will still be placed under dst. As such, this obj.starts_with(&dst) check is always true. * Always hash the file prefix * Fix error handling of objects_from_files * Fix nightly warning
If a source file was specified by absolute path, then the corresponding
object file was placed into OUT_DIR. This posed a problem if multiple
files with the same base name were specified by absolute paths.
Fixes #683.