extend --dep-info flag with variant that emits just the list of files to stdout

[pnkfelix]

For whipping up a quick makefile, I would prefer to be able to just call the command to generate the list of filenames.

The current workaround, AFAICT, would be to generate the dep-info to a temporary file, and then parse the that output to remove the target-filename: prefix that comes before the list of deps.

[pnkfelix]

�Now that I've implemented the workaround myself, it seems simple enough to do within one's tool. So this is not a terribly high priority, and in fact maybe I'll close it. (The only reason I have not closed this ticket already is that it does seem weird that we only support emitting the filenames in the makefile dependency format,.)

[SiegeLord]

Now that I've implemented the workaround myself, it seems simple enough to do within one's tool. So this is not a terribly high priority, and in fact maybe I'll close it.

While it is true it wasn't that hard to work around, I think its easier to redirect to a file when a file is required, rather than the reverse.

we only support emitting the filenames in the makefile dependency format

One issue that I hit in my CMake macros with this is that this precludes filenames with spaces in them, despite CMake, in principle, supporting them with some backends (e.g. via Ninja, afaik).

[pnkfelix]

@SiegeLord of course, any output format has to deal with the embedded spaces problem in the general case ... what do you think a hypothetical --dep-info-list output to stdout should do for them? The main options I can think of are:

• Put delimiters around each path (such as a pair of ''s). Of course this then just complicates file names with embedded quotes, or whatever other delimiter is used.
• Use a separator other than space to separate the entries. One obvious option is newline... then one can use xargs to reassemble that output to a single line, and many line-oriented unix tools should work reasonably well with this option.

I am making an implicit assumption here that paths with embedded spaces are more common than embedded newlines or embedded quotation marks; does that sound right?

An aside: The last time I had to wrestle with embedded spaces on a serious project, I ended up bailing on trying to handle the embedded spaces themselves (which were coming from absolute paths on good old Windows), and instead I changed the build infrastructure so that configure generated relative paths to the source. (So your project itself was not allowed to have files with embedded spaces, but you could at least put your build underneath a directory that did have embedded spaces, such as "My Documents" or whatever it is called.)

---

(A sad thing is that adopting either of these proposals will make my typical use case harder, but that's okay.)

[SiegeLord]

Truth be told, I was thinking of using newlines. I note that our other build-system helpers already have issues with filenames with newlines in them (e.g. --crate-name, --crate-file-name). If this is a legitimate concern, then I'd suggest adding a --separator option that'd switch all of them to a different separator (either user defined, or NULL).

On Unix, the expectation is stdout unless told otherwise. rustc --help lists it as --dep-info [FILENAME], i.e. optional filename.

rustc --dep-info lib.rs: ICE. Which is actually the better result, compared to losing my file.

[steveklabnik]

The original motivation here has been subsumed by Cargo, is this still something we would want?

[SiegeLord]

The original motivation here has been subsumed by Cargo, is this still something we would want?

Not sure how, as Cargo can't generate makefiles. In many ways, a makefile is still easier/less intrusive than creating a cargo project. Additionally, cargo isn't something that will be accepted in places like Debian which are very conservative about what build systems are allowed (although maybe not, if cargo is bundled with rustc).

To the extent that --dep-info still exists, it's behaviour is still a bit annoying. In some ways it's gotten worse, as it now appends a pointless '.d' to the output file name.

Cargo is actively hostile to being used as/with a system package manager: rustc can't link to /usr/lib when installed there because it completely ignores the FHS, distros will never accept an ecosystem that builds its own set of C libraries for that reason alone, and even if they did, they won't package it because Cargo doesn't even plan to support offline/restricted builds for use in build bots and source-based package managers where you're verboten to touch anything outside the build tree, including the network.

If Rust is ever going to become a Systems Language(tm) in the sense that we implement system libraries to be built, installed and depended on with standard system utilities, Cargo will need a serious overhaul.

[huonw]

Triage: nothing has happened here for a long time; @pnkfelix, do you still think this would be useful?

[pnkfelix]

yeah I'll just close this.

I still think there's a good case that this problem should be fixed, but its probably part of a more general overhaul to integrate better with tools other than cargo.