freeswitch/libs/libsndfile
2014-03-19 17:37:02 +00:00
..
Cfg
doc
examples
M4
man
Octave
programs
regtest
Scripts
src don't require python for libsndfile build 2014-02-24 14:02:22 -05:00
tests
Win32
.update
acinclude.m4 add more missing in acinclude.m4 2014-02-21 19:04:57 -05:00
AUTHORS
autogen.sh
binheader_readf_check.py
ChangeLog
configure.ac Tweak sndfile for args 2014-03-19 17:37:02 +00:00
configure.gnu
COPYING
echo-install-dirs.in
INSTALL
libsndfile.spec.in
make_lite.py
Makefile.am fully disable pkgconfig, we don't install this anyways 2014-02-24 10:17:21 -05:00
Mingw-make-dist.sh
NEWS
README
README.md
reconfigure.mk
sndfile.pc.in
TODO

libsndfile

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

Building on Linux, OSX and Windows (Using GNU GCC) will require a number of GNU and other Free and Open Source Software tools including:

If you are on Linux, its probably best to install these via your Linux distribution's package manager.

If you want to compile libsndfile with support for formats like FLAC and Ogg/Vorbis you will also need to install the following optional libraries:

Support for these extra libraries is an all or nothing affair. Unless all of them are installed none of them will be supported.

$ ./autogen.sh

Running autogen.sh also installs a git pre-commit hook. The pre-commit hook is run each time a user tries to commit and checks code about to be committed against coding guidelines.

Nest step is to run configure, with the following configure options being recommended for anyone contemplating sending libsndfile patches:

$ ./configure --enable-gcc-werror

Finally libsndfile can be built and tested:

$ make
$ make check

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.