xmake leaves a lot of junk in /tmp

[davidchisnall]

Xmake Version

v2.7.1+master.20e5768e3

Operating System Version and Architecture

FreeBSD 14

Describe Bug

After running xmake, there are a lot of files left in ~/.xmake{uid}. This is surprising to new users and inconsistent with most other build systems, where all state is contained within the build directory.

This is problematic for a few reasons:

• /tmp is often fairly small and so is more of a constrained resource than space in the build directory.
• /tmp is often a memory-backed filesystem and so leaving long-lived files there can degrade system performance over time between reboots.
• The build directory is often a filesystem configured for write speed and so we lose any advantages from that by using /tmp.
• It makes it harder to sandbox xmake runs because now it writes to files in locations other than the designated work directory.

Expected Behavior

All state should be stored in the build directory.

Project Configuration

No response

Additional Information and Error Logs

No response

[waruqi]

Those are only temporary files and are not used to keep the project in a build state. All project-related status files are stored in the build directory.

In addition, xmake will start a cleanup task in the background the first time it is run each day to clean up all temporary files from yesterday, so /tmp/ will only hold temporary files from just one day. like this /tmp/.xmake501/220901, 2022-09.01

And xmake only stores a few small temporary files in the /tmp directory.

[davidchisnall]

Can you document what they are? Running xmake -v, I saw that it was asking my compiler to store the dependency files there (that's how I noticed that it was storing stuff in /tmp to begin with). That sounds like build state to me.

[waruqi]

Most of the dependency information is stored in the build/.deps directory.

$ find ./build/.deps/ -name "*.d"
./build/.deps//demo/macosx/x86_64/release/demo.d
./build/.deps//demo/macosx/x86_64/release/src/demo/demo.c.o.d
./build/.deps//demo/macosx/x86_64/release/src/demo/libc/wcstombs.c.o.d
./build/.deps//demo/macosx/x86_64/release/src/demo/libc/string.c.o.d
./build/.deps//demo/macosx/x86_64/release/src/demo/libc/mbstowcs.c.o.d
./build/.deps//demo/macosx/x86_64/release/src/demo/libc/wchar.c.o.d
./build/.deps//demo/macosx/x86_64/release/src/demo/libc/time.c.o.d

and there may be some compilation rules that are not configured to automatically use temporary file paths due to dependency file paths.

First, I need to know which file you are talking about and its contents so that I can know which rules store and use it and can determine if there are possibilities for improvement.

[davidchisnall]

The clang command-lines that -v was showing me were passing a /tmp path to the -M* flags, but now (after some modifications to my xmake.lua) it doesn't seem to be passing them at all, though if I dump target:sourcebatches() it shows them in .deps in my build directory (though it's not adding the flags and the dependency files don't exist after I deleted and recreated my build directory, so I'm not sure how it thinks its calculating dependencies).

For context, I am evaluating xmake as a replacement for CMake targeting an embedded system. It's difficult in CMake to hook into different parts of the build system and, in particular, difficult to add new kinds of objects (or new properties on existing objects). Xmake looks a lot better in this regard, but the learning curve is a lot steeper. If I can hide most of that from users then it's worthwhile but I want to make sure that I understand what's going on and what users should or shouldn't need to care about. I started using the existing rules and am now adding custom ones (and reading the code to figure out how to do some undocumented things such as adding a new platform. Adding a new target kind looks a bit too hard, which is unfortunate because we have a few different kinds of library-like constructs.).

[waruqi]

The clang command-lines that -v was showing me were passing a /tmp path to the -M* flags, but now (after some modifications to my xmake.lua) it doesn't seem to be passing them at all, though if I dump target:sourcebatches() it shows them in .deps in my build directory (though it's not adding the flags and the dependency files don't exist after I deleted and recreated my build directory, so I'm not sure how it thinks its calculating dependencies).

xmake uses a temporary file to fetch the dependency information specified by -MF, parses it and stores it in the build/.deps/xxx.d file, and then automatically deletes the temporary file at the end. There is nothing wrong with this, the temporary file is very short-lived.

[davidchisnall]

xmake uses a temporary file to fetch the dependency information specified by -MF, parses it and stores it in the build/.deps/xxx.d file, and then automatically deletes the temporary file at the end. There is nothing wrong with this, the temporary file is very short-lived.

Thanks, that makes sense. The files seemed to be left around at the end (I had 350KiB of temporary stuff from xmake from a project with a single source file), I guess they're cleaned up by the background process periodically. I'd prefer that they were in the build directory, but that's purely a cosmetic preference.

[ZtRXR]

我再一次构建当中发现xmake留下了900mb的垃圾，导致我的tmp目录被塞满，影响正常使用，希望能改进

$ sudo du -ah /tmp | sort -rh | head -n 10
952M    /tmp/.xmake1000/240808
952M    /tmp/.xmake1000
952M    /tmp
404M    /tmp/.xmake1000/240808/_29CAB960B81D4B308763495FCF86EE50
273M    /tmp/.xmake1000/240808/_24165A692865461089A8BB4D9456ED30
264M    /tmp/.xmake1000/240808/_B938D031DEF240008290ADB88D772510
5.0M    /tmp/.xmake1000/240808/_6282182313F449108EA18C922C380540
4.1M    /tmp/.xmake1000/240808/_D4EDADF87F4B48308C3716674B2A5670
2.8M    /tmp/.xmake1000/240808/_4DFF422F216248308827CF137C6EF840
132K    /tmp/.xmake1000/240808/stats/240808

[ZtRXR]

似乎是因为我在运行xmake test后程序输出了很多内容导致的

[ZtRXR]

我建议不要把程序test时输出的内容放在/tmp中，这容易造成隐患，程序在stdout中有可能输出很多内容