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>