[llvm-dev] [Path] RFC: Known directories

Aaron Ballman via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 23 12:30:16 PST 2015


On Mon, Nov 23, 2015 at 3:27 PM, Rafael EspĂ­ndola
<rafael.espindola at gmail.com> wrote:
> On 23 November 2015 at 15:11, Aaron Ballman <aaron.ballman at gmail.com> wrote:
>> On Mon, Nov 23, 2015 at 3:07 PM, Rafael EspĂ­ndola
>> <rafael.espindola at gmail.com> wrote:
>>>> We appear to use both system_temp_directory(true) and
>>>> system_temp_directory(false) in ways that seem like they could matter.
>>>> For instance, modules uses a temp directory that does not get erased
>>>> on reboot, possibly for performance reasons. Do we gain something from
>>>> deprecating system_temp_directory()?
>>>
>>> I have a small preference for having the distinction in the name:
>>>
>>> *_temp_* -> something that is one use and potentially deleted often
>>> *_cache_* -> something we would like to save (modules for example).
>>>
>>> So what we gain is clarity over a bool parameter.
>>
>> We already have user_cache_directory, and it means something different
>> than system_temp_directory(false) today.
>
> It was just added. My understanding was that the intention was for it
> to have the correct semantics for things like clang modules. Maybe we
> should
>
> * Rename user_cache_directory to just cache_directory
> * Adjust it semantics so that it can be used in cases that currently
> uses system_temp_directory(false).
> * Replace remaining uses with temp_directory.
>
> That is, in the end we would have only
>
> * temp_directory
> * cache_directory
> * home_directory
>
> What do you think?

I would be okay with that. The caller should never really care about
whether a directory is system-wide or user-specific anyway, at least
in terms of temp and cache.

Thanks!

~Aaron


More information about the llvm-dev mailing list