I would be nice to have a few more "how to use" lines in the readme

[travisdowns]

For example, it seems like .travis.yml uses cmake (for the tests), so this is a cmake project that pops out a library that I should link against (it seems not - cmake is just for tests?)? If I look at a module like cpu that has cpu.h and cpu.c do I just drop those into my project (probably not that simple since they may depend on other modules)?

Maybe something like a default-use case scenario, and then for any modules that don't follow that pattern a note in the readme.

[nemequ]

The cmake stuff is just for tests, you shouldn't use it.

Usually you just drop them in to your project, they should work is pretty much any C/C++ compiler without any special flags or anything. Sometimes there are dependencies across modules (for example, see https://github.com/nemequ/portable-snippets/blob/master/endian/endian.h#L14). I try to keep those optional, but it can be hard to avoid without duplicating tons of stuff, so the safest thing is to just drop the whole portable snippets into your project, then just use the files you want.

There are a couple of places where compiler/linker flags may be significant (the clock module is a good example), the module-specific readmes should document them.

The CPU module depends on the once module, which will try to use pthreads on most non-Windows platforms, but can fall back on atomics if that's not available. In that case, it will also need the atomic module. With the exception of linking to pthreads if it's available, this all happens transparently (assuming you have all the modules). If you don't want to go through all that, you can easily tweak it to not be thread safe; just call it once before you involve threads if possible (only the first operation writes anything).

[travisdowns]

Yup, I'm already building with cpu.c fine in my project, but a summary of this info would definitely be good for new users I think.