diff options
| -rw-r--r-- | README.md | 155 |
1 files changed, 155 insertions, 0 deletions
diff --git a/README.md b/README.md new file mode 100644 index 0000000..0fe0485 --- /dev/null +++ b/README.md | |||
| @@ -0,0 +1,155 @@ | |||
| 1 | # libbu++ | ||
| 2 | |||
| 3 | Libbu++ is a general purpose, cross-platform utility library for C++. It | ||
| 4 | covers a huge range of topics including compression and encryption, string | ||
| 5 | handling, containers, networking, and more. | ||
| 6 | |||
| 7 | Libbu++ is also under constant development, this means that some API may change | ||
| 8 | over time, but we try to make sure that everything stays as compatible as | ||
| 9 | possible. | ||
| 10 | |||
| 11 | ## License | ||
| 12 | |||
| 13 | Libbu++ is distributed under a rather permissive BSD-like license, full details | ||
| 14 | are included in the file LICENSE included. | ||
| 15 | |||
| 16 | If these terms are insufficient or you desire alternative licensing, please | ||
| 17 | contact Xagasoft. | ||
| 18 | |||
| 19 | ## Why libbu++? | ||
| 20 | |||
| 21 | I created libbu++ originally to try out some container classes like a hash | ||
| 22 | table, linked list, and some specialized trees for some game projects. It's | ||
| 23 | evolved since then, but started being used more and more when we discovered that | ||
| 24 | it was faster and had a smaller memory footprint than alternative libraries on | ||
| 25 | some systems. | ||
| 26 | |||
| 27 | Some libraries are faster, and some libraries may have more features, but very | ||
| 28 | few of them are also as free as libbu++ is. Hopefully, libbu++ will continue | ||
| 29 | to evolve and get faster, more stable, and fully featured. | ||
| 30 | |||
| 31 | A few things that are easy to do cross platform with libbu++: | ||
| 32 | |||
| 33 | * Threading | ||
| 34 | * Stream handling (files, sockets, memory buffers) | ||
| 35 | * Stream filters (compression, encryption, base64, hex, and more) | ||
| 36 | * Formatting values and complex objects as text | ||
| 37 | * Serialization | ||
| 38 | * Creating network servers and clients | ||
| 39 | * Random number generation | ||
| 40 | * Type safe signals and slots | ||
| 41 | * Uuids (guids) | ||
| 42 | * Managing settings in platform specific storage systems | ||
| 43 | * Unit testing | ||
| 44 | |||
| 45 | Some specific, unique features: | ||
| 46 | |||
| 47 | * Myriad, a block-allocated stream multiplexing file format | ||
| 48 | * MyriadFS, a posix-compliant file system built on top of Myriad | ||
| 49 | * TAF, the Textual Archive Format which makes config files and metadata easy | ||
| 50 | to deal with. | ||
| 51 | * MiniCron, a cron-like system for executing | ||
| 52 | |||
| 53 | ## Requirements | ||
| 54 | |||
| 55 | Personally, I've only compiled using gcc (g++) 4 series, information on | ||
| 56 | success building with other compilers is greatly appreciated. | ||
| 57 | |||
| 58 | Libraries: | ||
| 59 | |||
| 60 | * libc | ||
| 61 | * libz | ||
| 62 | * bzip2 | ||
| 63 | * lzma | ||
| 64 | |||
| 65 | The RegEx class is currently a wrapper around the glibc regex functions. | ||
| 66 | Development is underway to replace that with a custom regex system, but until | ||
| 67 | then the Regex class will not compile on any systems that do not have this | ||
| 68 | functionality (ahem, Windows). | ||
| 69 | |||
| 70 | If you want to compile without libz, bzip2, lzma, or regex support, simply | ||
| 71 | delete the respective files before compiling. Each of these is only used in | ||
| 72 | one class internally (a .cpp and .h file). | ||
| 73 | |||
| 74 | For windows, a copy of libz and bzip2 all compiled and ready to go for mingw | ||
| 75 | are included (32bit). | ||
| 76 | |||
| 77 | ### GNU/Linux | ||
| 78 | |||
| 79 | This is the platform I do all my work on, it should work great. | ||
| 80 | |||
| 81 | ### Windows | ||
| 82 | |||
| 83 | I've only tried building libbu++ against MingW, the 32 bit version. It works | ||
| 84 | quite well except for the regex functions not being available. | ||
| 85 | |||
| 86 | ### Mac OSX | ||
| 87 | |||
| 88 | I don't own a mac, but I would love to support the Mac. Unfortunately that's | ||
| 89 | difficult to do. I have had successful builds on OSX, but Mac support may be | ||
| 90 | lagging behind by a decent amount. | ||
| 91 | |||
| 92 | ## Compiling | ||
| 93 | |||
| 94 | The preferred method for building libbu++ is using Xagasoft build. It also | ||
| 95 | includes a Makefile since build isn't really very standard yet. The Makefile | ||
| 96 | simply tries it's best to compile as much of the library as possible. It will | ||
| 97 | also setup a directory called *bu* in the libbu++ directory and create symlinks | ||
| 98 | to all library header files there to simulate an installed system. | ||
| 99 | |||
| 100 | Currently, only a static link library is built to make development easier. | ||
| 101 | |||
| 102 | To install you can use the ./checkinst.sh script included, this will setup | ||
| 103 | libbu++ using only symlinks so that you can update and develop while maintaining | ||
| 104 | a standard installation model. | ||
| 105 | |||
| 106 | I haven't written a real install target for build or make yet, the assumption | ||
| 107 | is that libbu++.a will be available in a standard location (e.g. /usr/lib) and | ||
| 108 | that the headers will be in a directory named bu in your system. | ||
| 109 | |||
| 110 | ## Using libbu++ | ||
| 111 | |||
| 112 | Either include the source code you want in your project, or build a library and | ||
| 113 | link against libbu++. In either case, each class gets it's own header file, | ||
| 114 | you can include them like this: | ||
| 115 | |||
| 116 | #include <bu/string.h> | ||
| 117 | #include <bu/sio.h> | ||
| 118 | #include <bu/file.h> | ||
| 119 | #include <bu/bzip2.h> | ||
| 120 | |||
| 121 | When you compile, just make sure you link against the library, and anything | ||
| 122 | else you may need, i.e. | ||
| 123 | |||
| 124 | g++ test.cpp -o test -lbu++ -lbz2 | ||
| 125 | |||
| 126 | ## File Layout | ||
| 127 | |||
| 128 | Within the src directory there are several sub directories: | ||
| 129 | |||
| 130 | * *stable* - All code in this directory is well tested, nearly fully featured, | ||
| 131 | and unlikely to change too much. | ||
| 132 | * *unstable* - All code in this directory is pretty well tested, working | ||
| 133 | towards becoming fully featured, but the API may change a little before it's | ||
| 134 | moved to stable. | ||
| 135 | * *experimental* - All code in this directory may or may not survive, and is | ||
| 136 | currently being tested. The API may change rapidly, or the code is being | ||
| 137 | developed currently. | ||
| 138 | * *tests* - Each .cpp file in this directory will be compiled into a | ||
| 139 | stand-alone executable. This is used primarily during development, the code | ||
| 140 | in these tests is generally turned into a unit test eventually and the test | ||
| 141 | file deleted. | ||
| 142 | * *unit* - This directory is full of .unit files used to generate libbu++ unit | ||
| 143 | tests. We could use a lot more unit tests, but there are a few good and | ||
| 144 | important ones so far. The libbu++ tool mkunit is used to turn .unit files | ||
| 145 | into .cpp source code. | ||
| 146 | * *tools* - Each source file in this directory becomes an executable, these | ||
| 147 | are built by default. | ||
| 148 | * *extra* - This directory includes source for programs that have extra | ||
| 149 | dependencies, or only work on particular operating systems. These are not | ||
| 150 | built by default. | ||
| 151 | * *doxy* - Doxygen is used for all documentation, this directory contains extra | ||
| 152 | guide pages and documentation that doesn't belong anywhere else. | ||
| 153 | * *compat* - Contains source files for specific platforms. | ||
| 154 | |||
| 155 | |||
