I'm personally very fond of the decade-old no-brainer solution that is bin2c[0]: convert a binary to a humongous .c file with an array literal. It's inefficient, and a bit stupid with source control, but it's entirely fool proof. Every compiler eats it. It just works. You compile it just once to a .o and then it doesn't slow down your build anymore.
If you just want the damn file in your executable and then move on with the stuff that actually matters, bin2c is a godsend.
From the C Include method part:
" On the downside, it requires at least five times the size of the original data (” 0xNN,” for every original data-byte) "
Can anyone explain this? In the example he shows, the tool produces an array of 12 bytes, the exact same size as the input file.
Perhaps he means encoding the data as ascii in the source is 5 times bigger than the original (i.e. 0xNN,), though I don't see why you have to write the data in the form 0xNN. Presumably you could just use a giant string, encoding non-ASCII characters.
You then need to escape characters that aren't legal in C string literals (such as double quotes, newlines and nul), and that's a lot more work than just converting the whole string. Also, string literals add a trailing nul byte, which is easy enough to deal with, but is also easy to forget about.
If you just want the damn file in your executable and then move on with the stuff that actually matters, bin2c is a godsend.
[0] one of the many implementations appears to be on https://github.com/gwilymk/bin2c