Genericize the CMake source generator for embedding files #1849

illwieckz · 2025-10-06T01:12:15Z

Extracted from #1842:

WIP: embed media files #1842

Extracted and polished. The design is now stable enough to be submitted for merging.

The bug I face in #1842 is unrelated to that code.

Usage example:

#include "DaemonEmbeddedFiles/EngineShaders.h"

void test()
{
	// Using a file directly using its symbol:
	const char* file = EngineShaders::common_glsl.data;

	// Loading a file by its name:
	const char* filename = "common.glsl";
	auto found = EngineShaders::FileMap.find(filename);
	const char* foundfile = found->second.data;

	// Iterating the files:
	for ( auto it : EngineShaders::FileMap )
	{
		Log::Debug("Embedded file %s at address %p with size %d", it.first, it.second.data, it.second.size);
	}
}

… embedding files

…ebugger opens it

illwieckz · 2025-10-06T01:30:32Z

Once this is merged, here are example of things you can do in a C++ file:

#include "DaemonEmbeddedFiles/EngineShaders.h"

void test()
{
	const char* filename = "common.glsl";

	// Reading a file content by its name:
	const char* file1 = EngineShaders::ReadFile(filename);

	// Using a file directly using its symbol:
	const unsigned char* file2 = EngineShaders::common_glsl;

	// Alternatively:
	const char* file3 = (const char*) EngineShaders::common_glsl;

	// Testing the presence of a file with a given name:
	Log::Debug("File %s is %s", filename,
		EngineShaders::ReadFile(filename) == nullptr ? "absent" : "present");

	// Iterating the files:
	for ( auto it : EngineShaders::FileMap )
	{
		Log::Debug("Embedded file %s", it.first);
	}
}

The unsigned char* and char* inconsistency was already there before.

…he target

illwieckz · 2025-10-06T01:58:24Z

Listing files to embed:

set(GLSL_EMBED_DIR "${ENGINE_DIR}/renderer/glsl_source")
set(GLSL_EMBED_LIST
	# Common shader libraries
	common.glsl
	common_cp.glsl
	fogEquation_fp.glsl
	shaderProfiler_vp.glsl
	shaderProfiler_fp.glsl
	# …
)

Generating the embedded files, etc:

	# Generate GLSL include files.
	daemon_embed_files("EngineShaders" "GLSL" "TEXT" "client-objects")

First option ("EngineShaders") is the wanted NameSpace, second option ("GLSL") is the SLUG used in GLSL_EMBED_DIR and GLSL_EMBED_LIST variable and list, the third option ("TEXT") selects the file format (selecting "TEXT" will strip the \r characters, selecting "BINARY" will apply no transformation), and the last option ("client-objects") is the target the generated source files contribute to.

Those variable and list should be named ${SLUG}_EMBED_DIR and ${SLUG}_EMBED_LIST with ${SLUG} being the same, as they are discovered based on the SLUG string passed to the daemon_embed_files() macro.

This daemon_embed_files() macro should be called after the target is defined (here, client-objects).

And that's all. It's even not needed anymore to add the entry points by hand like this:

set(RENDERERLIST
	${DAEMON_EMBEDDED_DIR}/EngineShaders.cpp
	${DAEMON_EMBEDDED_DIR}/EngineShaders.h
	${ENGINE_DIR}/renderer/BufferBind.h
	# …
)

…tside)

slipher · 2025-10-06T08:57:44Z

So this will be used for the Vulkan binary shaders list?

I guess the separate EMBED_DIR and EMBED_LIST thing was designed for VFS embedding; if we don't need that it seems over-complicated. Just use a single list of absolute paths like everything else.

Note that the GLSL map that we have now is coded in a rather inefficient way. The map object stores the files as std::string, but the original char arrays are still there, so we have 2 copies of the files at all times. Then when you read out a file a 3rd copy is created... it would be better for the map to have a StringView or something.

It doesn't make sense to me that some auxiliary functions return char* because that would be unusable for binary files. In any case I doubt we need those; just the map is a good enough interface.

…s to regenerate the target

VReaperV · 2025-10-07T02:50:39Z

So this will be used for the Vulkan binary shaders list?

Vulkan will use functionality that was already added in #1845, which is now rebased on this pr.

illwieckz · 2025-10-07T06:23:56Z

So this will be used for the Vulkan binary shaders list?

I don't know yet if that's usable for the Vulkan binary, but with the latest iteration the embedded file should be directly accessible as a constexpr unsigned char*.

I guess the separate EMBED_DIR and EMBED_LIST thing was designed for VFS embedding; if we don't need that it seems over-complicated. Just use a single list of absolute paths like everything else.

Not only, it's easier to paste the path without having to add the prefix boiler plate. I prefer to set the DIR once than copypasting the DIR for every file.

Note that the GLSL map that we have now is coded in a rather inefficient way. The map object stores the files as std::string, but the original char arrays are still there, so we have 2 copies of the files at all times. Then when you read out a file a 3rd copy is created... it would be better for the map to have a StringView or something.

Ouch that's awful!

That should be better now, the map is now a map of a name and a pair of const unsigned char* data pointer and size_t size.

It doesn't make sense to me that some auxiliary functions return char* because that would be unusable for binary files. In any case I doubt we need those; just the map is a good enough interface.

I removed the ReadFile() function because with the latest iteration those two lines were fundamentally different and we should avoid confusion:

const char* text_ptr = EngineShaders::ReadFile(filename);

audioFile = FS::PakPath::ReadFile(filename);

Our other ReadFile() functions (like the second one) return a std::string with known size, while we now embed a const char* without bound checking (but the size is stored right next to it). So I removed the code for the first line to avoid deadly confusions.

It's unsafe to access the const unsigned char* array without reading the size too. For the GLSL code that expects text, we don't have to read the size because I added a null terminator at the end of every files. The size stored in the pair is the size of the original file (without the null terminator), so when copying it in a std::string (for example in the FileSystem code) we would not copy that extra null terminator that is only there for codes like the GLSL code reading the const unsigned char* array directly as a text buffer.

illwieckz · 2025-10-07T21:43:54Z

Here is an example of how the current implementation works in the C++ code:

void test()
{
	// Using a file directly using its symbol:
	const char* file = (const char*) EngineShaders::common_glsl;

	// Loading a file by its name:
	const char* filename = "common.glsl";
	auto found = EngineShaders::FileMap.find(filename);
	const char* foundfile = (const char*) found->second.data;

	// Iterating the files:
	for ( auto it : EngineShaders::FileMap )
	{
		Log::Debug("Embedded file %s at address %p with size %d", it.first, it.second.data, it.second.size);
	}
}

illwieckz · 2025-10-07T21:51:09Z

The map is just a convenience for accessing the files, the map just stores the name, the size and the pointer to the data, so I assume the compiler will drop the map when the data is only accessed directly.

This should fit the need for:

What we already do for the GLSL shaders.
Embedding a file and loading it directly, for things like builtin images like $white, as an alternative to write a generator if a bit complex to write.
Exposing a builtin pak in memory to the VFS, including exposing it to the virtualized game, with the ability to list files and load them using the existing VFS mechanism.

This code was tested with my builtin pak implementation, so the only thing I haven't tested is the direct access (more than compiling the above code) is the direct access, but that should work.

slipher · 2025-10-08T11:33:34Z

src/common/EmbeddedFile.h

@@ -0,0 +1,7 @@
+struct embeddedFileMapEntry_t


You can use Str::StringRef. There's no reason to be using unsigned char instead of char for the data

There's no reason to be using unsigned char instead of char for the data

I tried:

In file included from GeneratedSource/DaemonEmbeddedFiles/EngineShaders.cpp:7: GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘226’ from ‘int’ to ‘char’ [-Wnarrowing] 137 | }; | ^ GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘137’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘164’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘226’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘136’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘154’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘226’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘137’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘165’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘226’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘136’ from ‘int’ to ‘char’ [-Wnarrowing] GeneratedSource/DaemonEmbeddedFiles/EngineShaders/fogEquation_fp_glsl.h:137:1: error: narrowing conversion of ‘154’ from ‘int’ to ‘char’ [-Wnarrowing]

Ah yes that's very inconvenient to work around at the level of defining the actual array, but we should reinterpret_cast any pointers to char as soon as possible because unsigned char is worse for all purposes.

cmake/DaemonFileEmbedder.cmake

slipher · 2025-10-08T11:36:35Z

cmake/EmbedText.cmake

+endif()
+
+# Add null terminator.
+string(REGEX REPLACE ",$" ",0x00," contents "${contents}") 


This shouldn't be using a regex replace since it is in a fixed location at the end.

Right, fixed.

slipher · 2025-10-08T11:57:18Z

cmake/DaemonSourceGenerator.cmake

@@ -0,0 +1,139 @@
+set(DAEMON_TEXT_EMBEDDER "${CMAKE_CURRENT_SOURCE_DIR}/cmake/EmbedText.cmake")


This "Text" naming scheme doesn't make that much sense now that it can handle binary files.

Yes, but I didn't want to rename that one in that PR for now. I was going to name it DaemonEmbeddedFile or something like that

Details here:

Genericize the CMake source generator for embedding files #1849 (comment)

slipher · 2025-10-08T12:01:22Z

cmake/DaemonSourceGenerator.cmake

+
+	file(MAKE_DIRECTORY "${embed_dir}")
+
+	foreach(kind CPP H)


The code in this loop is too confusing. I shouldn't have to sit here half an hour trying to decipher this code using multiple variable indirection to do something that probably could have been done by just setting a variable to a hard-coded string.

This kind of indirection saves me a lot of time when rewriting and re-rewriting across my various iterations , and it already saved me a lot of time. It only looks better to hardcode those strings when all the work was done by someone else, because then you don't know all the hundreds of different strings that have been used before being presented to the final state. Those indirections aren't only written to reduce the amount of lines to edit when redesigning things, but also to avoid the introduction of mistakes when editing the alternative expanded boiler plate.

And we know well who is doing all those iterations and who will suffer from editing the duplicated boiler plate once it is expanded:

git ls-files | grep -i cmake | while read f; do git blame -w -M -C -C --line-porcelain "$f" | grep -I '^author '; done | sort -f | uniq -ic | sort -n --reverse 2135 author Thomas Debesse 1286 author TimePath 612 author slipher 334 author Daniel Maloney 243 author Corentin Wallez 175 author Darren Salt 161 author dolcetriade 135 author VReaperV 108 author Amanieu d'Antras 107 author perturbed 43 author Tsarevich Dmitry 29 author Morel Bérenger 12 author Mattia Basaglia 7 author Tim 3 author cmf028 2 author Jesper B. Christensen 1 author maek 1 author Keziolio

It only looks better to hardcode those strings when all the work was done by someone else,

Yes that's the point. Other people besides you should be able to read the code.

I meant: You don't know yet what's the cost of maintaining it is.

I can tell you it's easier this way, because I already maintained it.

Said other way: this is the solution I have chosen because I first tried the hardcoded way and it was painful and doing it this way made it easier. Lessons got learned, I share you the result, I save you time.

slipher · 2025-10-08T12:03:53Z

CMakeLists.txt

 endif()

-include(DaemonBuildInfo)
+include(DaemonSourceGenerator)


Name seems inapt, how about DaemonFileEmbedding? Or alternatively something about "resources" since that is a commonly used term for embedding files in this way.

Just DaemonEmbed? That's what I did in #1845 until I rebased on this pr.

DaemonEmbed or a variant of it (DamonEmbeddedFile?) is the naming I'm planing to use for EmbedText that doesn't only produce embedded text files anymore.

Also this cmake does more code generation than just embedding files (like the buildinfo thing).

Details here:

Genericize the CMake source generator for embedding files #1849 (comment)

slipher · 2025-10-08T12:08:56Z

cmake/DaemonSourceGenerator.cmake

+endmacro()
+
+macro(daemon_embed_files basename slug format targetname)
+	set(embed_source_dir "${slug}_EMBED_DIR")


This variable name concatenation will make the code hard to understand later. For example if you search for GLSL_EMBED_DIR you will not find anything; the variable seems to be unused.

It's better than boilerplate.

This mechanism also makes possible to embed files with paths having directories in them, the previous code only supported basename and it was then also making assumptions in the back of the user that were more painful and more limiting.

This mechanism also makes possible to embed files with paths having directories in them, the previous code only supported basename and it was then also making assumptions in the back of the user that were more painful and more limiting.

That's a separate question. You can have directory names in the path without magical variable concatenation. The function can take two arguments - base dir variable and file list variable.

I modified it to pass variables instead.

illwieckz · 2025-10-16T15:30:54Z

This now uses file(GENERATE …) instead of daemon_write_generated).

That now looks ready to me.

slipher · 2025-10-19T03:13:06Z

Looking pretty good but I still want to ask that Str::StringRef or Str::StringView be used to provide a handle to the data instead of a thing with unsigned char *. It's an annoying interface to give people a string made of unsigned chars.

illwieckz · 2025-10-31T17:35:08Z

I don't know how to make it use a Str::StringRef there.

slipher · 2025-11-01T06:53:35Z

I don't know how to make it use a Str::StringRef() there.

A StringRef could be constructed like {reinterpret_cast<const char*>(byte_array), sizeof(byte_array) - 1}

…char

illwieckz · 2025-11-01T13:23:47Z

This is accepted by the compiler:

const Str::StringRef screen_fp_glsl = reinterpret_cast<const char*>( data_screen_fp_glsl );

This isn't:

const Str::StringRef screen_fp_glsl = { reinterpret_cast<const char*>( data_screen_fp_glsl ),
 sizeof ( data_screen_fp_glsl ) - 1 };

But the first one has then screen_fp_glsl.size() set to 0. It's not problematic for the GLSL code since it's treated as a null-terminated string, but I would like this code to be compatible with binary files that may contain valid non-terminating null bytes, and for this I need object.size() to work.

Also with the first implementation (without the size), with some more elaborated embedded file code than the GLSL one I get some errors about embeddedFileMap_t members not having .second() because of being Str::BasicStringRef instead of having it as .second(). I don't know what compiler optimization madness happens to get that error, but that's not a problem I had with my custom srtuct.

illwieckz · 2025-11-01T13:41:19Z

It looks like I need to add a new Str::StringRef constructor for that.

slipher · 2025-11-01T13:42:38Z

Oops, I didn't realize we were missing that constructor. See #1872

illwieckz · 2025-11-01T13:44:17Z

Yes, I just added a new constructor on my end (but without the assert) and it worked.
I'll use yours as it is more complete.

illwieckz · 2025-11-01T13:50:26Z

Yours has a chicken-and-egg problem about the ASSERT definition. I'm currently using the simpler constructor without assert while waiting for the assert-featured one to work.

illwieckz · 2025-11-01T16:03:44Z

I modified the code to be standalone (no dependency from src/common), it's better this way.

illwieckz · 2025-11-01T21:02:32Z

For some unknown reasons code becomes simpler with that dedicated struct than with Str::StringRef.

For example when testing this code with #1842, here is what I need to do with Str::StringRef:

for (auto& p : builtinPakMap[pak.name])
{
	if (p.first == path)
	{
		const Str::StringRef& entry = p.second;
		std::string out;
		out.resize(entry.size());
		memcpy(&out[0], entry.data(), entry.size());
		return out;
	}
}

While I can do this simpler code with the simple dedicated struct:

const embeddedFileMapEntry_t& entry = builtinPakMap[pak.name][path];
std::string out;
out.resize(entry.size);
memcpy(&out[0], entry.data, entry.size);
return out;

With Str::StringRef I face very weird type errors and I would need the convoluted code to avoid them.

slipher · 2025-11-02T09:25:20Z

For example when testing this code with #1842, here is what I need to do with Str::StringRef:

for (auto& p : builtinPakMap[pak.name])
{
	if (p.first == path)
	{
		const Str::StringRef& entry = p.second;
		std::string out;
		out.resize(entry.size());
		memcpy(&out[0], entry.data(), entry.size());
		return out;
	}
}

StringRef has automatic conversion to string so you could do

	if (p.first == path)
	{
		return p.second;
	}

Anyway it's fine with me as long as the interface doesn't used unsigned char. LGTM

illwieckz · 2025-11-08T20:13:00Z

So, here are usage examples of the API that is implemented in the code that has been merged:

#include "DaemonEmbeddedFiles/EngineShaders.h"

void test()
{
	// Using a file directly using its symbol:
	const char* file = EngineShaders::common_glsl.data;

	// Loading a file by its name:
	const char* filename = "common.glsl";
	auto found = EngineShaders::FileMap.find(filename);
	const char* foundfile = found->second.data;

	// Iterating the files:
	for ( auto it : EngineShaders::FileMap )
	{
		Log::Debug("Embedded file %s at address %p with size %d", it.first, it.second.data, it.second.size);
	}
}

illwieckz added 6 commits October 6, 2025 02:09

cmake: rename DaemonBuildInfo as DaemonSourceGenerator

db9a7cd

DaemonSourceGenerator: rework it a bit

530c3ba

DaemonSourceGenerator: make the embedded file generator reusable

275f03b

EmbedText make possible to chose between TEXT and BINARY formats when…

3f9e92f

… embedding files

DaemonSourceGenerator: provide embedded files as part as the namespace

5e0ce3f

EmbedText: split embedded source lines just in case if an editor or d…

291613e

…ebugger opens it

illwieckz added T-Improvement Improvement for an existing feature A-Build T-Feature-Request Proposed new feature labels Oct 6, 2025

DaemonSourceGenerator: also add the generated source entry-point to t…

16236af

…he target

illwieckz force-pushed the illwieckz/cmake-embed branch from 9b96078 to 1313666 Compare October 6, 2025 01:58

DaemonSourceGenerator: lowercase local variables (even if the leak ou…

cef003a

…tside)

illwieckz force-pushed the illwieckz/cmake-embed branch 2 times, most recently from a7ff720 to 945511f Compare October 6, 2025 05:31

illwieckz added 3 commits October 7, 2025 01:44

DaemonSourceGenerator: also make generated source depend on generator…

e9f7e6d

…s to regenerate the target

DaemonSourceGenerator: explicit mkdir

39ce492

DaemonSourceGenerator: do not copy the embedded files in the map

5a57364

illwieckz force-pushed the illwieckz/cmake-embed branch from 95677da to ff5cf6c Compare October 7, 2025 06:14

illwieckz mentioned this pull request Oct 8, 2025

engine code requires some shaders and assets currently shipped as game assets #71

Open

slipher reviewed Oct 8, 2025

View reviewed changes

cmake: rename EmbedText as DaemonFileEmbedder

05ae5b5

illwieckz force-pushed the illwieckz/cmake-embed branch from ff5cf6c to 6978bf5 Compare October 8, 2025 23:39

DaemonSourceGenerator: use explicit variable names

4885b09

illwieckz force-pushed the illwieckz/cmake-embed branch from c5da974 to 2bdccd1 Compare October 16, 2025 15:29

illwieckz force-pushed the illwieckz/cmake-embed branch from 2bdccd1 to b3d0517 Compare October 31, 2025 17:34

DaemonFileEmbedder: make it fully standalone, do not expose unsigned …

5c7bc3f

…char

illwieckz force-pushed the illwieckz/cmake-embed branch 2 times, most recently from 77fee60 to a0fd2b3 Compare November 1, 2025 16:02

illwieckz force-pushed the illwieckz/cmake-embed branch 5 times, most recently from 56b6260 to e38f914 Compare November 1, 2025 20:18

illwieckz mentioned this pull request Nov 1, 2025

WIP: embed media files #1842

Draft

illwieckz force-pushed the illwieckz/cmake-embed branch 3 times, most recently from c2d2350 to 5c7bc3f Compare November 2, 2025 00:37

illwieckz merged commit 9c1bbb0 into master Nov 8, 2025
9 checks passed

illwieckz deleted the illwieckz/cmake-embed branch November 8, 2025 20:02

		@@ -0,0 +1,139 @@
		set(DAEMON_TEXT_EMBEDDER "${CMAKE_CURRENT_SOURCE_DIR}/cmake/EmbedText.cmake")

Genericize the CMake source generator for embedding files #1849

Genericize the CMake source generator for embedding files #1849

Conversation

illwieckz commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

illwieckz commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

illwieckz commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Listing files to embed:

Generating the embedded files, etc:

Uh oh!

slipher commented Oct 6, 2025

Uh oh!

VReaperV commented Oct 7, 2025

Uh oh!

illwieckz commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

illwieckz commented Oct 7, 2025

Uh oh!

illwieckz commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

illwieckz commented Oct 16, 2025

Uh oh!

slipher commented Oct 19, 2025

Uh oh!

illwieckz commented Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

slipher commented Nov 1, 2025

Uh oh!

illwieckz commented Nov 1, 2025

Uh oh!

illwieckz commented Oct 6, 2025 •

edited

Loading

illwieckz commented Oct 6, 2025 •

edited

Loading

illwieckz commented Oct 6, 2025 •

edited

Loading

illwieckz commented Oct 7, 2025 •

edited

Loading

illwieckz commented Oct 7, 2025 •

edited

Loading

illwieckz commented Oct 31, 2025 •

edited

Loading