This is the deadbeef plugin build system, as the name implies.
This tool is for plugin developers, and not for end users.
It allows to write a simple configuration file, and build a statically linked cross-distro binaries for your plugin using the "build" tool, both for i686 and x86_64.
The tool called "build-md" can be used to generate markdown file, which will be used for publishing all plugins on the deadbeef website.
Each plugin has a subfolder in the "plugins" folder, and a manifest.json in it.
Example: plugins/bs2b/manifest.json
The folder can also have patch(es), referenced from manifest.
- fetching sources from svn, hg, git
- patching
- building with GNU Make (make->type=make)
- building with autotools (make->type=autotools)
- generating packages (versioned zip files)
- extracting descriptions/authorship/licenses (this would have to be written in the manifests)
- generating the final plugin downloads page
- x86_64 linux distro with ia32libs installed (build on i686 also works, but no cross-compilation to x86_64)
- wget, tar, bzip2 for downloading and unpacking dependencies
- perl
- make, autotools for building
- deadbeef installed
- alternatively, unpack this into static-deps/lib-x86-32 and static-deps/lib-x86-64
- Hosted on the internet, using svn, hg or git (no tarballs supported here).
- Using GNU make or autotools. If your plugin uses anything else -- you'll have to write a Makefile, and supply it as a patch.
- Ability to link the dependencies statically. The static versions of many libs are supplied automatically by this system. If there are no static libs for the stuff that your plugin needs -- you're out of luck for now. Make a feature request to add the lib(s) which you need.
./build --arch=i686 bs2b ddb_waveform_seekbar
./build --arch=x86_64 --nofetch ddb_filebrowser
This is useful when trying to make a patch, more on this below.
When you're adding a new plugin to the system, in most cases, you'll need to apply a patch, so that it works with static linking. Many plugins use weird build systems, such as shell scripts, cmake, qmake, etc. Even when they use makefiles or autotools -- there are bugs, which prevent to build the static binaries. So when you make the manifest, and run "build" - you'll get errors. Or you simply won't be able to build, because the plugin uses e.g. cmake. So you'll need to add a Makefile. Of course, the best way to do this, is to fix your code. But if for some reasons you don't want to do it, or you're not the developer of the plugin -- you'll need to create a patch, and reference it from the manifest.json. Look at how it's done in other plugins.
(assuming you're testing on x86_64)
- Run
./build --arch=x86_64 pluginname
- Look at the errors, and correct them in the cached sources (
temp/pluginname
) - Re-run
./build --nofetch --arch=x86_64 pluginname
. Notice the--nofetch
. If you don't use--nofetch
-- your local modifications will be lost! - Repeat until you're happy with the result, then do something like
git diff >../../plugins/pluginname/buildfixes.diff
, and add the patch into manifest.
- Clone this repository
- Run
./build --arch=x86_64
to verify that everything works. All plugins should build without errors. NOTE that the 1st time you run it -- a large archive with libraries will be downloaded. - Create a new folder with manifest.json file for your plugin. Copy a manifest.json from any other plugin as a template, try to find one which looks close to what you need. E.g. using the same VCS, same build system, same libraries, etc.
- run
./build --arch=x86_64 pluginname
. The pluginname here is the name of the folder you've created. - Fix the errors in the manifest. Fix the errors in the code. Rerun with --nofetch argument, so that your changes are not deleted.
- Repeat step 5, until the plugin builds completes successfully. At this point, you may create a patch. See the section
How to make a patch
above for instructions. - Verify that the plugin builds without errors. Copy the plugin to a place where deadbeef can find it. Run deadbeef, and verify that your plugin works.
- Run readelf -d on all your *.so files, to verify they link to what they need to link.
- After this is done - you're ready to submit a pull request. Hopefully you know how to do it. If not -- please refer to github manual.