Go to file
2017-03-08 20:51:08 +11:00
CMake libsndfile.cmake: Set __USE_MINGW_ANSI_STDIO as needed 2016-07-07 19:53:00 +10:00
doc Delete doc/dither.html 2016-11-08 06:50:46 +11:00
examples Compile tests only when running 'make check' 2017-01-28 21:16:21 +11:00
M4 Test whether -D_FORTIFY_SOURCE needs to be added at all 2017-01-28 21:16:21 +11:00
man Fix spelling errors 2016-07-20 20:05:38 +10:00
Octave Do not use old variable INCLUDES and use modern AM_INIT_AUTOMAKE invocation. 2013-04-07 20:05:08 +10:00
programs Make 'test-sndfile-metadata-set.py' py2/py3 compatible 2017-01-28 21:16:21 +11:00
regtest Compile 'sndfile-regtest' only when sqlite3 is available 2017-01-28 21:16:21 +11:00
Scripts Scripts/static-deps-build.mk: Restore file 2016-11-27 18:02:44 +11:00
src src/rf64.c: Fix writing of PAD chunk 2017-03-08 20:51:08 +11:00
tests src/sndfile.c: Check return of write_header() 2017-01-30 21:48:56 +11:00
Win32 Remove cruft from Win32 dir. 2008-10-08 21:19:23 +11:00
.gitattributes Add .gitattributes file 2016-09-06 18:17:43 +10:00
.gitignore Remove 'INSTALL' file, as it is part of the cruft automake installs always 2017-01-28 21:16:21 +11:00
.travis.yml .travis.yml: Switch from Ubuntu Precise to Trusty 2015-12-07 19:28:22 +11:00
AUTHORS AUTHORS : Add contributors. 2014-09-02 06:17:37 +10:00
autogen.sh autogen.sh: Only add hook if .git exists 2016-11-14 05:54:15 +11:00
Building-for-Android.md Add file Building-for-Android.md 2016-07-16 22:07:41 +10:00
ChangeLog Fix some typos. 2014-10-27 06:17:57 +11:00
CMakeLists.txt CMake: More fixes 2016-07-03 14:14:17 +10:00
configure.ac Add AM_PROG_AR to configure.ac 2017-01-28 21:24:23 +11:00
COPYING First snapshot of the public project. 2007-05-14 19:55:24 +10:00
echo-install-dirs.in Use pkgconfigdir variable as it is not sure it will be libdir/pkgconfig. 2013-04-28 21:35:08 +10:00
libsndfile.spec.in libsndfile.spec.in : Change field name 'URL' to 'Url'. 2011-12-19 20:22:34 +11:00
make_lite.py Clean out cruft. 2008-04-05 20:13:47 +11:00
Makefile.am Refactor generation of test-suite 2017-01-28 21:16:21 +11:00
NEWS Version 1.0.27 2016-06-19 18:08:54 +10:00
README Version 1.0.27 2016-06-19 18:08:54 +10:00
README.md README.md: Add libasound to the list of build deps 2016-07-28 21:15:59 +10:00
sndfile.pc.in sndfile.pc.in: missing update from 95828ca2 2016-04-30 07:29:07 +10:00

libsndfile

Build Status

libsndfile is a C library for reading and writing files containing sampled audio data.

Hacking

The canonical source code repository for libsndfile is at https://github.com/erikd/libsndfile/.

You can grab the source code using:

$ git clone git://github.com/erikd/libsndfile.git

For building for Android see BuildingForAndroid.

There are currently two build systems; the official GNU autotool based one and a more limited and experimental CMake based build system. Use of the CMake build system is documented below.

Setting up a build environment for libsndfile on Debian or Ubuntu is as simple as:

sudo apt install autoconf autogen automake build-essential libasound2-dev \
    libflac-dev libogg-dev libtool libvorbis-dev pkg-config python

For other Linux distributions or any of the *BSDs, the setup should be similar although the package install tools and package names may be slightly different.

Similarly on Mac OS X, assuming brew is already installed:

brew install autoconf autogen automake flac libogg libtool libvorbis pkg-config

Once the build environment has been set up, building and testing libsndfile is as simple as:

$ ./autogen.sh
$ ./configure --enable-werror
$ make
$ make check

The CMake build system.

The CMake build system is still experimental and probably only works on linux because it still relies on GNU autotools for bootstrapping. Using it as simple as:

$ Scripts/cmake-build.sh

I would be happy to accept patches to make the CMake build system more portable.

Submitting Patches.

  • Patches should pass all pre-commit hook tests.
  • Patches should always be submitted via a either Github "pull request" or a via emailed patches created using "git format-patch".
  • Patches for new features should include tests and documentation.
  • Patches to fix bugs should either pass all tests, or modify the tests in some sane way.
  • When a new feature is added for a particular file format and that feature makes sense for other formats, then it should also be implemented for one or two of the other formats.