Re: Add a configure option for NATIVE_FULL_AOT?

[Gunnar Horrigmo]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gunnar Horrigmo <horrigmo@runbox.no>
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >
>> > AFAIR, the main argument against using the XDG's cache was that the
>> > definition of its purpose didn't fit, and that XDG directories are
>> > ephemeral.
>> 
>> I don't know why that is a problem, but if it is, then the right place
>> would be $XDG_STATE_HOME or $XDG_DATA_HOME? I think? 
>
> What is the definition of "state files" and "data files" for this
> purpose?  Just be considering the usual meaning of these, *.eln files
> are neither, but maybe the Freedesktop definitions are not "usual".

| $XDG_DATA_HOME defines the base directory relative to which
| user-specific data files should be stored. If $XDG_DATA_HOME is either
| not set or empty, a default equal to $HOME/.local/share should be
| used.
| 
| $XDG_STATE_HOME defines the base directory relative to which
| user-specific state files should be stored. If $XDG_STATE_HOME is
| either not set or empty, a default equal to $HOME/.local/state should
| be used.
| 
| The $XDG_STATE_HOME contains state data that should persist between
| (application) restarts, but that is not important or portable enough
| to the user that it should be stored in $XDG_DATA_HOME. It may
| contain:
| 
|     actions history (logs, history, recently used files, …)
| 
|     current state of the application that can be reused on a restart
|     (view, layout, open files, undo history, …)

So I guess you're right about XDG_STATE_HOME. But I think we should be 
free to define what data is ourselves?

There is also this, just for completeness sake:

| $XDG_RUNTIME_DIR defines the base directory relative to which
| user-specific non-essential runtime files and other file objects
| (such as sockets, named pipes, ...) should be stored. The directory
| MUST be owned by the user, and he MUST be the only one having read
| and write access to it. Its Unix access mode MUST be 0700.
|
| The lifetime of the directory MUST be bound to the user being logged
| in. It MUST be created when the user first logs in and if the user
| fully logs out the directory MUST be removed. If the user logs in more
| than once he should get pointed to the same directory, and it is
| mandatory that the directory continues to exist from his first login
| to his last logout on the system, and not removed in between. Files in
| the directory MUST not survive reboot or a full logout/login cycle.
|
| The directory MUST be on a local file system and not shared with any
| other system. The directory MUST by fully-featured by the standards of
| the operating system. More specifically, on Unix-like operating
| systems AF_UNIX sockets, symbolic links, hard links, proper
| permissions, file locking, sparse files, memory mapping, file change
| notifications, a reliable hard link count must be supported, and no
| restrictions on the file name character set should be imposed. Files
| in this directory MAY be subjected to periodic clean-up. To ensure
| that your files are not removed, they should have their access time
| timestamp modified at least once every 6 hours of monotonic time or
| the 'sticky' bit should be set on the file.

That said, I really didn't mean to challenge already made decisions.
Especially in the runup to 28. I'm perfectly happy to live with the
current situation.


>> >> I won't attempt to revive that discussion, but is there some guidance on
>> >> how to configure this in .emacs (probably not, but by any means), so we
>> >> can have a more... compliant environment (if you'll excuse the term)?
>> >
>> > I don't think I have a clear understanding of what you want to
>> > achieve, so please tell more.
>> 
>> I simply want to store the .eln files in an XDG defined directory, even
>> if you guys think I shouldn't. :)
>
> You can always customize native-comp-eln-load-path, can't you?

I can indeed. I guess this is what I originally meant to ask. Thank you
for the pointer, and sorry for the disruption. I should have
investigated instead of letting my OCD panic. :)

-- 
Gunnar