[mmfZ4e4OqQ7RRwP]

You copy the nimbase.h file along with the nimcache/*.c files. That's it. The compiler doesn't do it because it's a waste of time/space copying a file which you most likely can include from somewhere else, and it's not a generated file.

[haberman]

Good to know. It would be nice if there was an option for the compiler to build a single .c file that was totally self-contained, for distribution purposes.

[mmfZ4e4OqQ7RRwP]

I don't know anybody who redistributes source code as a single C file, but you could try concatenating the files into one. Usually people redistributing source code don't mind having several files bound together by some make|build script. The nim compiler has the --genScript switch to make one. Most people willing to get something redistributable prefer a binary static|dynamic library or final executable.

[haberman]

> I don't know anybody who redistributes source code as a single C file

SQLite pioneered this approach, called an Amalgamation. It offers some noticeable advantages:

https://www.sqlite.org/amalgamation.html

It is gaining some followers:

https://github.com/vinniefalco/Amalgamate

http://stackoverflow.com/questions/2719311/tool-to-create-an...

http://lua-users.org/lists/lua-l/2008-08/msg00594.html

> Usually people redistributing source code don't mind having several files bound together by some make|build script.

A single .c file is easier to integrate into various build systems. For example a Visual Studio project, or another Makefile without needing a separate script. It's just cleaner.

> Most people willing to get something redistributable prefer a binary static|dynamic library or final executable.

These aren't portable like a C source file is.