dblaikie added a comment. In D139774#4066574 <https://reviews.llvm.org/D139774#4066574>, @aaron.ballman wrote:
> 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. I'd be willing to roll the dice on that - my guess is it wouldn't be too bad - but just guessing. (as all good/difficult design discussions are - debating predictions of the future based on our respective experience) >> 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? If (1) is sufficient for KDevelop's needs and already implemented in some form for clangd, if I understand correctly, that seems the cheapest/least involved? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139774/new/ https://reviews.llvm.org/D139774 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
