[Path] RFC: Known directories

Hi,

llvm::sys::path allows the user to query “known directory” paths: temp, cache, home. I was tweaking this area a bit for some time. I would like to propose a small redesign.

What we have so far?

home_directory() tries to return what it promises. No issues with that.

system_temp_directory(true) returns a path to a directory that can be erased on reboot. On Linux it is usually /tmp. On Windows and OSX it returns user’s temp directories as a first choice.

system_temp_directory(false) returns a path to a directory that is not cleared on reboot. On Linux it is usually /var/tmp. On Windows is the same as system_temp_directory(true). On OSX it is user’s cache directory.

user_cache_directory() returns a path to user’s cache directory.

Redesign proposal:

  1. Add function temp_directory() - a replacement for system_temp_directory(true). If it returns system or user temp directory is OS-specific. Same as system_temp_directory() it always succeed.
  2. Implement system_temp_directory(bool) in terms of temp_directory() and user_cache_directory().
  3. Deprecate system_temp_directory(bool).
    Comments?
  • Paweł

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()?

~Aaron

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.

Cheers,
Rafael

We already have user_cache_directory, and it means something different
than system_temp_directory(false) today.

~Aaron

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?

Cheers,
Rafael

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

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?

Great. That was more/less my proposition. I will send patches when I find a bit more of free time. Thanks.