Jack Andersen via llvm-dev
2021-Dec-11 23:48 UTC
[llvm-dev] Expanding response file's base directory
I am looking for thoughts on how feasible it would be to have CommandLine.cpp's ExpandResponseFiles generate paths relative to the response file itself. Essentially, this involves transforming a reserved character sequence into the base path of the response file. Of course this would be trivial to implement, but the main consideration here is to avoid breakage for existing users. The reserved character sequence could contain shell operator characters, thereby eliminating the vast majority of accidental transformations. A reserved word would reduce this probability even further. I would like to propose "<cfgdir>" as a possibility. This would be a valuable feature for deploying portable, non-installed directories containing clang .cfg files and items for the toolchain to use without further search path arguments from the user. Use case: ```sample_target_sdk.cfg --target=sample_target -isystem <cfgdir>/include -L <cfgdir>/lib ```
Jack Andersen via llvm-dev
2021-Dec-12 23:18 UTC
[llvm-dev] Expanding response file's base directory
A preliminary patch is available at <https://reviews.llvm.org/D115604>. `<cfgdir>` has been replaced with `<@>` to reflect the relationship with `@` expansions. On Sat, 11 Dec 2021 at 18:48, Jack Andersen <jackoalan at gmail.com> wrote:> > I am looking for thoughts on how feasible it would be to have > CommandLine.cpp's ExpandResponseFiles generate paths relative to the > response file itself. Essentially, this involves transforming a > reserved character sequence into the base path of the response file. > Of course this would be trivial to implement, but the main > consideration here is to avoid breakage for existing users. The > reserved character sequence could contain shell operator characters, > thereby eliminating the vast majority of accidental transformations. A > reserved word would reduce this probability even further. > > I would like to propose "<cfgdir>" as a possibility. > > This would be a valuable feature for deploying portable, non-installed > directories containing clang .cfg files and items for the toolchain to > use without further search path arguments from the user. > > Use case: > > ```sample_target_sdk.cfg > --target=sample_target > -isystem <cfgdir>/include > -L <cfgdir>/lib > ```