You don't need to #include the C file itself. Treat it as you would any C file in your project. Add it to your IDE project, preferably in the same directory tree as your own source files, make sure the header file is in on your include path, #include the header in any source module in which you want to use it, and compile.

Sorry for the noise. I assumed incorrectly there was an associated header file.

Looking at the file in question and comments like "end of header file" suggest that the author dumped the .h and .c into a single file for... download convenience? Laziness? Lack of a zip tool?

The "clean" way is to split the file into a header and a source file. If you just want to #include the whole thing, make sure there is never ever more than a single .c/.cpp file that does so.

Assuming the file came from here, you're supposed to define STBI_HEADER_FILE_ONLY before including the source file like a "header" file, and then simple add the .c file to your project. I personally think it's a stupid setup, but oh well. For example:

YourFile.h

// Each file that depends on stb_img.c can "properly" include like this:
#define STBI_HEADER_FILE_ONLY
#include "stb_img.c"
 
// blah blah blah...

Then simply add stb_img.c to your project.

Assuming the file came from here, you're supposed to define STBI_HEADER_FILE_ONLY before including the source file like a "header" file, and then simple add the .c file to your project. I personally think it's a stupid setup, but oh well. For example:

YourFile.h

// Each file that depends on stb_img.c can "properly" include like this:
#define STBI_HEADER_FILE_ONLY
#include "stb_img.c"
 
// blah blah blah...

Then simply add stb_img.c to your project.

this isn't entirely atypical for "single file whatever" style things.

it is a tradeoff though, like either it is something like this, or distributing the code as multiple files (or as a more conventional library).

another issue is maintainability, as a single giant source file becomes a mess to work on (in this case, placing a practical limit on how much can be done in a single source file).

some libraries "solve" this problem by then developing the library as multiple files, and then bundling them into a single giant C file for sake of other people using them in the project (hey, random programmer, how do you feel about a 4MB C source file?...). (side note: SQLite...).


well, it is either this, or expect people to be able to figure out how to use multiple files, or make it a traditional library (and deal more with the matter of different compilers and build targets), ... (and sometimes people who get really annoying and whine in terror that getting their stuff to build might happen to involve having to edit or customize a Makefile and/or figure out how to include all the files into a VS project or similar, or start playing the blame game and making a huge fuss about whose responsibility it is to make sure the code works on their target OS/compiler/... of choice, ...). (vs people taking it on themselves to edit the code and makefiles to work on their target of choice if they feel so inclined... like FFS they are getting the code for free...).