[PATCH] D65430: Add `--dependency-files` option, which is equivalent to compiler option -MD.

[Petr Hosek via Phabricator via llvm-commits]

phosek added a comment.

In D65430#1739394 <https://reviews.llvm.org/D65430#1739394>, @MaskRay wrote:

> In D65430#1739325 <https://reviews.llvm.org/D65430#1739325>, @phosek wrote:
>
> > In D65430#1616208 <https://reviews.llvm.org/D65430#1616208>, @MaskRay wrote:
> >
> > > `#pragma comment(lib, "b.a")` is not common. If the build system goes through the trouble to use deplibs,
> >
> >
> > These are already being used by libc++ and libc++abi so I wouldn't say it's uncommon.
> >
> > > there may likely be other post processing steps. I wonder if it can just point `-fuse-ld=` to a custom wrapper that processes `ld.lld -t` output and generates `$out.link.d`.
> >
> > This sounds like a lot of extra effort that would have to be replicated in every build system that would like to use the depfile support (i.e. every build that wants to use linker depfiles would need such wrapper and integrate it into their build).
>
>
> See my analysis at https://reviews.llvm.org/D65430#1616208 , I don't think the in-tree C++ implementation reduces complexity for other build systems. It works for Ninja, but not even for Make.
>
> > The implementation of this feature is very minimal and doesn't significantly increase the linker complexity so I don't understand why there's so much pushback?
>
> We've been innovative in introducing useful options. That is a good thing. But we've already gotten similar features in this area (e.g. `--trace`, `--verbose`). The pushback is about the generality of a feature. The question raised in https://reviews.llvm.org/D65430#1616208 is never answered. I hope we can be aware of feature creep. Ideally we just implement powerful and orthogonal features that can meet a wide range of demand, instead of inventing a new option for every feature request that only differs from the previous ones in some nuance.


That's fair, but I don't feel like we've been upholding that principle in the past and I don't understand why we should start right now. For example, we've introduced a number of features that are specific to Android: `-use-android-relr-tags`, or Partitions <https://lld.llvm.org/Partitions.html>. We've also added IDE specific features: `-vs-diagnostics`. While it's true that depfiles could only be utilized by Ninja at the moment, Ninja is being used as a backend for multiple build systems: CMake, GN, Meson, Blueprint, kati, to name the most popular ones. This already seems like a much higher bar than for the other features.

To try and answer your questions from https://reviews.llvm.org/D65430#1616208, there are two different use cases I mentioned before, deplibs is one of them, input linker scripts is the other one. Regarding the issue with Make, could we address that using the same approach as `-MP` does by generating a phony target for each dependency other than the main file? For your example we would generate the following depfile:

  a: b.a
  b.a:

I do agree that Makefile format is not great, but it's what existing compilers and build systems already use and support so it seems like the most pragmatic option for now. I know there's a discussion about introducing a new (possibly JSON based) depfile format for C++ modules, and if that indeed happens and build system implement support for this format, we could extend lld to support the new format as well, but I don't think we should be blocking this feature on that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65430/new/

https://reviews.llvm.org/D65430