[kazinator]

It looks like olive.c is a "single header" library. They chose a .c suffix rather than .h.

If OLIVE_IMPLEMENTATION is defined before including "olive.c", then the full implementation is produced. Otherwise, just declarations, so that it behaves like a header file.

It's a valid technique. If you have a library all in one source file, the requirement to have a separate .h doubles your file count.

One small reason to have a .c suffix is might be that your editor can then choose a more specific syntax scheme. A .h file could be C++. Another one is that it can be used as a source file. You can pop it into a Makefile project, and just make sure you have -DOLIVE_IMPLEMENTATION on the compiler command line for that file. Other files using it just include "olive.c" to get the declarations. Because it has a .c suffix, make will handle it via its .c.o rule.

[jandrese]

This feels far messier to me than just having a .h file.

[kazinator]

Sure, but let's look at the larger picture. If you have one file, then that's your deliverable. You can host that file somewhere, send it as an e-mail body, drop it into a paste-bin or whatever. It is one self-contained unit.

If you have two files: .h and .c, the use scenario may be simpler. Not a lot though. And now youu have two files which have to stay together somehow, yet remain distinct. If you combine them in one body of text, you have to indicate: oh, please snip out this part as a .h file and then the rest as a .c file. In e-mail you can have it as two separate MIME attachments. You can use an archive file --- have you looked into the formats? Not so simple.

It's not hard to understand the attraction to the one file deployment, even if you don't do it yourself.

[mrweasel]

Can you do something like what SQLite does an squash the .h and .c into one file, but also have multiple files for those who are doing development or just like separate files?

[kazinator]

Yes, I can, and so can you, without a doubt.

If I wanted to distribute a single file library, but have the two file option for users, I'd make it so that a specific Awk one-liner produces the two. For instance, the file might look like this:

   #ifndef FOOBAR_LIB_H_D3B94F3C
   #define FOOBAR_LIB_H_D3B94F3C

   // header stuff here

   #endif // FOOBAR_LIB_H_D3B94F3

   #if FOOBAR_LIB_IMPL

   // impl here

   #endif

Then to people who want two, I would say, just run this command in your shell and paste the content into it:

   awk 'BEGIN { print "#include \"foobar.h\"" > "foobar.c"
                print "#define FOOBAR_LIB_IMPL" > "foobar.c" }
        /#ifndef FOOBAR_LIB/,/#endif.*FOOBAR_LIB/ { print > "foobar.h"; next }
        { print > "foobar.c" }'

that way I wouldn't need a build step on my end to generate parallel files.

I would have the extra build step if it were a large project of multiple .c files that I wanted to deploy as a single file for the users who want that. (Not only would I build the single file out of multiple files, but also have some test cases which actually use it. Things have ways of breaking when you combine files, like giving the same name two two static variables or functions in different files.)

[worthless-trash]

Its part of the spec, and not even obscure. this is not even scratching the surface of nightmare level C.

[Brian_K_White]

In this case, 2 files is a failure and blows the whole point. 2 files means a tgz and might as well be 50 files.