[PATCH] D139774: [libclang] Add API to set temporary directory location

Thu Jan 19 11:03:54 PST 2023

aaron.ballman added a comment.

In D139774#4066519 <https://reviews.llvm.org/D139774#4066519>, @dblaikie wrote:

> I've mixed feelings about this, but yeah, I guess the issues with global state are pretty undesirable. I don't worry too much about (2) - doesn't feel too problematic to me (for any individual file, presumably the implementation recorded the name of the file if they were going to access it again - so still be using the old path if necessary).

FWIW, #2 relates to #3 for me -- it's not that I worry the compiler will guess the wrong path, it's more that I worry users will get confused because some temp files go in one place while other temp files go in another place, and they file issues we track down to timing issues.

> But, yeah, lack of any "system" abstraction that could be passed into all the various LLVM/MC/AST contexts to swap out the implementation limits the options a bit to more ad-hoc/case-by-case solutions. I feel like that's not a great solution to KDevelop's general problem, though - they're dealing with one particularly big file, but it doesn't feel very principled to me to fix that one compared to all the other (albeit smaller) temp files & maybe at some point in the future some bigger temp files are created elsewhere...
>
>> So my preference is for components to have an option to pick a different location as part of their API layer, rather than at the lower level. Based on that, I'm definitely in support of #1, and I'm in support of one of the options for #2. I lean towards #2b over #2a due to wanting individual overrides rather than a blanket override (e.g., we should be able to put preamble files in a different location than we put, say, crash logs).
>>
>> @dblaikie does that sound reasonable to you?
>
> (1) seems OK-ish, I guess there's some question as to what the tradeoff is for that option - does that blow out memory usage of the client/kdevelop? But I guess it's probably fine.

Do you think we should do one of the options for (2) or do you think (1) should be sufficient?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139774