||3 years ago|
|meson||3 years ago|
|.gitignore||3 years ago|
|LICENSE||4 years ago|
|README.md||3 years ago|
|build||3 years ago|
Osmia is a busy little bee of a build script for meson projects. It works around some of meson's stranger design decisions. It's primarily targetted at C development at the moment, and it's a bash script, so it only works where bash is available.
The end goal of this thing is basically to lose all its features to Meson over time. For example, there's no reason I can see that calling 'meson' again shouldn't just run ninja for you. Most features of Osmia should be considered bugs against Meson.
Meson fills its directory with a mix of files you might want to interact with and meson internal files. Osmia provides "bin" and "lib" directories full of symlinks so that you don't have to hunt around inside the meson build-and-internals combination directory to find what you need.
Meson doesn't provide tools to automatically procure and build dependencies without a meson file. This means that you cannot use a dependency without a meson build system, and sometimes you just really need to do that, even though it sucks. Osmia fills this gap, poorly, with its 'meson/dependencies' file.
Meson sometimes requires one of two separate commands ("meson" or "ninja") to build. Osmia figures out which command(s) currently need to be run to build and does it for you.
At the time of this writing, meson will attempt to use ccache, but will stop using it once you specify some different compiler to back it with. Osmia attempts to guess the compiler you want, (Clang, GCC, others. In that order.) but can also be told to use a specific compiler with "CC=". When specifying a compiler this way, ccache will still be automatically used if available.
Using Meson alone, it's unclear to users unfamilliar with meson how to build your software. By providing a simple ./build script that walks them through missing dependencies (meson, ninja, optionally ccache), osmia makes it easier for end users to build your software. Meson couldn't realistically fix that, but it's a nice side-benefit for using osmia.
Osmia stays out of Meson's way, so you can always use the standard Meson/ninja build commands instead of or in addition to the osmia wrapper.
Drop the "build" file into your project at the root directory and run it ("./build") when you want to build.
./build [-mode] [target]
Target will be passed to ninja directly
Mode defaults to 'release', or can be one of the following:
- -? -h --help
- Prints out a help dialogue
- -r --release
- Builds using meson's release mode. Default.
- -d --debug
- Builds using meson's debug mode, with --werror added
- -c --clean
- Cleans up current project meson/ninja/osmia files
- -w --win --windows
- Cross-compiles for win32 using meson/win32.txt
- -w64 --win64 --windows64
- Cross-compiles for win64 using meson/win64.txt
- -o --osx
- TODO. Cross-compile for OSX using meson/osx.txt
Osmia will return appropriately when called, so you can do constructs such as: ./build -d && ./bin/mytest
If you have subprojects, osmia will assume they're in meson/ (Or $MDIR/). You will need to inform meson of this by adding "subproject_dir : 'meson'" to your project line.
Other meson oddities
Meson looked at the available options of C or python and picked python. Osmia can't help with the speed tradeoffs inherent in that decision.
Meson demands that the root directory of projects contain 'meson.build' and 'meson_options.txt'. I have not been able to work out any method of hiding that mess. I tried. Hard.