diff options
| author | Thomas Hindoe Paaboel Andersen <phomes@gmail.com> | 2014-02-03 22:27:46 +0100 |
|---|---|---|
| committer | Kay Sievers <kay@vrfy.org> | 2014-02-03 22:32:13 +0100 |
| commit | 9afb9180f343f9b616694185c722ce452692d85b (patch) | |
| tree | b55c0080def0d6d835c2c570f1195b7e6370fce4 | |
| parent | 3618ef288c381ad9afd48e2a440785cedc7b4b51 (diff) | |
| download | libabc-9afb9180f343f9b616694185c722ce452692d85b.tar.gz | |
README: typo fixes
| -rw-r--r-- | README | 12 |
1 files changed, 6 insertions, 6 deletions
@@ -36,17 +36,17 @@ Why bother? nice, and give them what they are used to. It makes their life a lot easier. -use autotools +Use autotools - Every custom config/makefile/build system is worse for everybody than autotools is. - We are all used to autotools, it works, nobody cares. - It's only two simple files to edit and include in git, which are well understood by many many people, not just you. - - Ignore all crap autotools create in the source tree. never check + - Ignore all crap autotools create in the source tree. Never check the created files into git. - Never, ever, install config.h. That's internal to your sources and is nothing to install. - - And really, anything but autotools is realy an option. Just get + - And really, nothing but autotools is really an option. Just get over it. Everything else is an experiment, and it will come back to you sooner or later. Why? think cross compilation, installation/ uninstallation, build root integration, separate object trees, @@ -73,11 +73,11 @@ Zero global state -- Make your library threads-aware, but *not* thread-safe! *every* program has loadable modules, think NSS! - Avoid locking and mutexes, they are very unlikely to work correctly, and incredibly hard to get right. - - Always use a library context object. every thread should then + - Always use a library context object. Every thread should then operate on its own context. Do not imply context objects via TLS. It won't work. TLS inheritance to new threads will get in your way. TLS is a problem in itself, not a solution. - - Do not use gcc constructors, or destructors, you can only loose if + - Do not use gcc constructors, or destructors, you can only lose if you do. Do not use _fini() or _ini(), don't even use your own explicit library initializer/destructor functions. It just won't work if your library is pulled in indirectly from another library @@ -198,7 +198,7 @@ Update NEWS to let developers know what has changed - If you want to provide ChangeLog, use the one generated by git, do not maintain your own. -use standard types +Use standard types - The kernel's u8, u16, ... correspond to uint8_t, uint16_t in userspace from <inttypes.h>. Don't define your own typedefs for that, don't include the kernel types in common headers. |