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

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 8 13:39:15 PST 2019


MaskRay added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65430





More information about the llvm-commits mailing list