[PATCH] D73951: [Clang] [Driver]Add logic to search for flang frontend

[Richard Barton via Phabricator via cfe-commits]

richard.barton.arm added a comment.

So, coming back to this after a few weeks break.

I agree with the point @awarzynski makes on this option being powerful and I think your alternative suggestion of using a different hard-coded name could work well at this stage of the project. I think the usecase that Carol and I were considering was for when building a clang/flang toolchain and renaming the binaries to something else. In that case, you would not want your driver to call to a hard-coded flang binary called "flang" but support calling to a flang binary called something else like "fooflang". In our case, we derive a commercial product from clang called armclang and I'm sure we are not the only ones doing something similar.

An additional thought I had was that we are in this situation today only because we need to name the binary "flang-tmp" because, as @awarzynski points out, "flang" is taken by the wrapper. This is because we are adding the new driver in the same place as the old driver, i.e. in flang/tools/f18. Firstly, that's a bad name for the new driver - f18 vs flang - and secondly perhaps it would be more clean to add the new driver as a new tool - e.g. flang/tools/driver and then make it a build-time configuration option which one to build in flang? That way we could bring the new driver up independently of the old driver and we would not be hitting this issue with the names. We would then not need this patch for the immediate issue we face today, although something similar may be needed to support the binary renaming case.

The other thing that has changed since the last round of review on this patch is that F18 <https://reviews.llvm.org/F18> is now part of the same project as clang, so perhaps we should be submitting both halves of this work at the same time.

I don't hold any of these views too strongly. I would be happy with the current approach or what @awarzynski proposes but have a mild preference for the current approach as I think it better addresses the binary renaming issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73951