Potential additions

[s9w]

• zstd has a compressions level setting. Currently that's fixed on the recommended level (3). That could be made configurable
• Other compressions?
• Currently, png, tga and bmp formats are read as images. That maybe should be configurable.

[GerHobbelt]

1. 💯 on the zstd compression level, i.e. zstd / lz4 compression configurable from the CLI. 🥳
2. re other compressors & other image formats: depends, can get pretty wild. 7z, xz, tar, gzip, zlib, zlib-ng, lzss & friends, webp, jpeg + jpeg-xl, etc.etc. 🤔 perhaps 'add on request when there's enough interest in format X'? (libarchive project might be of interest there - with their load-from-memory API)
3. If you mean to configure PNG et al as either 'store as bitmap image' or 'store as direct raw PNG data': that might indeed be handy for some 'loading embedded resource' situations. (wxWindows' custom asset providers come to mind, but I still need to look into those for another project, so this is just a far-fetched hunch right now.)

Anyway, my 2 cents.

Thanks for the tool!

[CihanSari]

For automation purposes:

• Treating some files differently should be configurable 💯.
• Folder / recursive / wild-card filters for adding files could make automation really easier. This could be merged to define which files are compressed, although I reckon we could just run it multiple times with unique configurations.
• Set output path for the payload file.
• Maybe some sort of optional caching option (don't perform the serialization if the file has not been modified), although this could be outsourced to the automation scripts.

[s9w]

Maybe some sort of optional caching option (don't perform the serialization if the file has not been modified), although this could be outsourced to the automation scripts.

For performance reasons? My encoding tests suggested that at the time encoding speed is measurable, compile metrics have long become an enormous problem. I optimized the encoder until file streaming became the most costly part of it I think. Although the allocation code for the string might hold some performance (not much though).

Configurable image file handling: Absolutely, I was thinking list of extensions in the config file? That would be easy and should fit most use cases. Are you're thinking further about per-file settings, varying compression etc @CihanSari?

Wildcards, folders: Not sure there. I really want to keep the "just drag files onto the exe" interface. Wildcards could get somewhat complex to implement. Not sure about the need.

For other compression and compression levels I lean towards waiting for requests in that direction.

I don't have strong opinions about any of this besides keeping the file dragging interface. Feel free to discuss etc.

[CihanSari]

I attempted an automation workflow where binary_bakery would be part of the build system and none of the other contributors would need to do things manually. In such a scenario, another contributor adds a new file to "resources" folder and can immediately use it on their project thanks to prebuild scripts. Here are some of my findings:

• Currently such a workflow would require multiple toml files (for each option list) and provide these files first in the list of files to bake. Wild cards could help identifying different folders / files when added by other users. The automation script could do this for us (generate toml files), and we could simply use the file list with the configuration file prepared.
• Each run would create the same payload file. It would make life easier if we could configure destination path to payload (path/to/payload.h).
• The file names don't need to conform with c++ member names. I already had more than a few files that caused issues. I would suggest we name the members differently while maintaining the string lookup exactly the same.
• Especially on relatively large projects we might need to keep relative paths (relative to what?) instead of only file names as there might be clashes. Imagine multiple index.html files on almost every folder that a webserver application wants to serve.
• Running the compression every time project is built is very taxing. Caching can be done in the automation script, or inside the payload file upon request (e.g. naive approach would be to keep last modify time of files, check against all, if none changed just exit). This would make automation really easier.

Regarding dependencies tomlplusplus doesn't seem to be supported on multiple platforms through vcpkg (https://vcpkg.info/port/tomlplusplus). Especially OSx and arm are important platforms to support imo. I am not sure if this is a shortcoming of the vcpkg or the library itself.

I agree on waiting before adding other compression methods. Adding an option to compression levels might be easier to accomplish, but we can wait until someone needs it. Moreover, we could also improve the interface and allow plugins (dynamic libs loaded on runtime) but I doubt this would be a big sell as long as people don't mind contributing and you don't mind checking the PRs.

[s9w]

I see - that automation workflow would have quite different performance expectations. Let's maybe make a new issue (or discussion) for that if there's more to discuss. That would be outside of my own needs and ability to test really, so you'll be on your own there. But it's cool!

I have no allegiance to either the toml format or that particular library. If there's an alternative that works better, let's just use that.

Plugins sound like a huge complexity increase. I'd vote for let's wait and see. At the point of publication, this has already received claims of over-engineering.