I imagine that many situations where you might want to embed assets into a binary involve embedded work. With embedded work you often want to be able to cross-compile. Requiring that the koio tool be built first on the host architecture (as opposed to the target architecture) gets messy, especially if you can't or don't want to depend on having it preinstalled.
The koio utility might better written in POSIX shell.
FWIW, here's a simple POSIX shell-compatible routine that will convert an 8-bit stream into a quoted C string
cstring() {
# use od to translate each byte to hexadecimal, sed to format as
# proper C string
od -An -tx1 -v | sed -ne '/./p' | sed -e '
# prefix \x to each hexadecimal pair and remove trailing space
s/\([0-9a-fA-F][0-9a-fA-F]\)[[:space:]]*/\\x\1/g;
# quote escaped bytes
s/^[[:space:]]*/"/;
s/$/"/;
# escape newline for all but the last line
$!s/$/ \\/;
'
}Even xxd has a mode to dump a file in the way expected by C. From then it's just another #include away.
I have been using a library named incbin (https://github.com/graphitemaster/incbin). On Mac and Linux it doesn't even require a cli tool to convert the file. It just embed the content using the `.incbin` directive of the inline assembler.
It is pretty perfect for my project, which is a deep learning application for Android. I use it to embed the CNN model file into the C++ code. It let me avoid putting it in the apk, and then loading it from Java, and then passing it to C++.
Are there any advantages vs just embedding the file as a char array? I've found it easier to mmap any input files anyway so as to avoid an extra level of buffering in userspace.
As other have already mentioned there are a lot of existing solutions to this problem. I'm not averse to reimplementing tools myself, but it you're going to do that it makes sense to add improvements along the way.
One obvious improvement would be to compress the stored data, via gzip/bzip/similar, which would result in a smaller binary. As a small side-effect the embedded resources would be less visible to anybody who ran "strings" against your binary.
I've been using bin2c for years.
this like looking back to the 80s when we coded for Amiga & Atari ST ...
Aren't there many tools out there that can already do this? I thought even objcopy(1) can turn an arbitrary file into a .o file containing a single symbol holding the data.