Follow the XDG Base Directory Specification

[hakan-demirli]

Closes #2060

[whitequark]

I think this isn't an accurate implementation.

1. The XDG base directories specification does not require XDG_DATA_HOME to be set and it is usually not set. So this would do nothing most of the time.
2. I think XDG_DATA_HOME isn't the right place to put .yosys_history. If you install Yosys with a prefix of ~/.local (which is a reasonable thing to do if you don't want to put it into /usr/local for some reason), it puts the files that usually go to /usr/share there, and history shouldn't be mixed with those. I think either XDG_CACHE_HOME or XDG_CONFIG_HOME should be used for this. (I did a quick search and on my system history files are placed in all three of data, config, and cache.) The issue you're referencing suggests XDG_CACHE_HOME so that's probably what should be used.

[hakan-demirli]

Yea, XDG_CACHE_HOME is more suitable for the history file.
As for setting the XDG variables I didn't want to break things by changing the location for the users who are not explicitly using XDG. Even though it is not spec compliant.

Is it OK to just obey the spec? Or should I create an extra env variable like other projects do: YOSYS_HISTORY_FILE. Since, users can set it to an XDG compliant location themselves.

[whitequark]

@nakengelhardt What do you think? To me it seems like the history file is not particularly important nor is its loss troublesome so a breaking change in the service of supporting the spec properly is fine here.

[nakengelhardt]

Reading the spec, wouldn't XDG_STATE_HOME be the appropriate directory?

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, …)

I don't think there's a point to having an extra variable, the people who care about where the files land can set the XDG variables (we should perhaps note that somewhere in the docs, but I'm not sure where would be a good place). The fallback is mostly for the people who don't really care and just want things to work, so I think what the spec says works fine there:

If $XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used.

I would be happy to change the fallback location to that, the one-time loss of contents of the history file is not a big deal IMO.

[hakan-demirli]

I accidentally requested review for the previous commit. I am sorry about that. It's my first time using PR on GitHub.

As requested fallback location is $HOME/.local/state and XDG_STATE_HOME is used if it exists.

[hakan-demirli]

Is there a Yosys way of checking if dir exists and create them?
There is a remove dir function but not create or check:

yosys/kernel/yosys.h

Line 345 in 6a7fad4

void remove_directory(std::string dirname);

I can either define a new function create_directory in yosys.h and use that.
Or I can do something like this in driver.cc:

#if defined(_WIN32) && !defined(__MINGW32__)
#  include <direct.h>
#  define mkdir(path, mode) _mkdir(path)
#  define stat(path, buffer) _stat(path,buffer)
#endif
#if defined (__linux__) || defined(__FreeBSD__)
#  include <sys/stat.h>
#  include <sys/types.h>
#endif

[mmicko]

@hakan-demirli please note that we build mingw build as main windows build (for oss-cad-suite) and for it _mkdir is in direct.h, so chec for _WIN32 is enough for that one, and sys/stat.h and sys/types.h are both available on mingw

[hakan-demirli]

I will clean the code since there are redundancies and unnecessary includes which are also coming from yosys.h. However it functionally works for all combinations of HOME and XDG_STATE_DIR. I will also test it with mingw.

However I have two questions.

• Should I put newly created functions inside yosys.h with an inline attribute? Or like a regular function with an implementation in yosys.cc?
• Boost libraries are listed as a dependency, but they are scarcely used. Why is that? 90 lines of code to create a directory tree is quite a tech burden imo. I have noticed similar patterns throughout the repo where one lines of cpp17 or boost code could clean tens of lines of code. I am sorry if this is an obvious/dumb question.

[whitequark]

• Boost libraries are listed as a dependency, but they are scarcely used.

Boost isn't a hard Yosys dependency. (There are some features that only work with Boost, but the base Yosys application can be built without Boost.)

[whitequark]

LGTM

[mmicko]

Have tested windows build and it creates directory correctly. However there is issue with log messages, they are never displayed.
Note that logger is initialized later in main function so actual log call does not do anything. So solution is to replace it with printf or fprintf but then it will not appear in logs at all, or to keep it as log but move this complete block after, that will make it also more visible to users.
Also log messages are missing \n so that needs fixing.

"Directory to put history file does not exist. If you are on Windows either $HOMEDRIVE or $HOMEPATH is empty."

maybe it should be (not sure about Windows part needed ).

"Unable to determine directory to put history file in.\n If you are on Windows either $HOMEDRIVE or $HOMEPATH is empty.\n"