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

[Paweł Bylica via llvm-dev]

On Mon, Nov 23, 2015 at 9:30 PM Aaron Ballman <aaron.ballman at gmail.com>
wrote:

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

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


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151123/fb00a643/attachment.html>