As Denemo is a free software you are strongly recommended to hack, patch and distribute its source code. Denemo is made of ≃75% C and ≃25% Scheme. You can clone the source from our git repository.Useful make targets are listed at maintainer page.
git clone git://git.savannah.gnu.org/denemo.git
Packages to install in order to build Denemo (some more recent versions now available):
- guile (1.8 or more)
- portaudio (19)
- smf (1.3 or more, shipped in the sources)
On .deb systems you can run as root:
apt-get install guile-1.8-dev libaubio-dev portaudio19-dev libfftw3-dev libgtk-3-dev libxml2-dev automake libtool libgtksourceview-3.0-dev libfluidsynth-dev autoconf libsmf-dev autopoint librsvg2-dev libportmidi-dev libsndfile1-dev libevince-dev librsvg2-dev librubberband-dev intltool gtk-doc-tools
If guile-1.8-dev is not available then you can replace that with guile-2.0-dev instead.
You can build denemo by running:
cd denemo ./autogen.sh # Run configure in another directory to not pollute your workspace with .o files mkdir bin && cd bin ../configure make
Note that you can adapt the build to your configuration with some ../configure options. To list available options type:
At each commit and before you send a patch, the program should be tested. You can check everything (testsuite, packaging process etc.) by running:
If you just want to run the testsuite:
make -C tests check
It uses GLib testing framework to launch tests.
You can test a single test by running:
gtester -p=/the/test/path the-test-binary
For example (from the tests directory):
gtester -p=/integration/run-and-quit integration
We use Travis as our continuous integration service. Basically. It compiles every commit on our repository with several compilators, run some tests and tell us if it was successful.
You can find here the full build report. The current status of Denemo is: .
If you can, please check that compilation and tests are successful before submiting a patch. It is very to use if you have a github account, where you can fork our mirror repository (it is synchronized every 10 minutes).
Coverage tools are useful to see which part of the code is reached, which is never tested, which functions are most called etc. on one program execution One can enable coverage on Denemo in a few steps:
- Install lcov to generate HTML reports. It is shipped with most of the distributions.
- Pass ‐‐enable-gcov parameter to ‘configure’
- Build denemo, you do not need to install it
- Launch denemo, play a bit with it, use some commands, then close it.
- Check that some .gcda and some .gcno files are generated in the src directory.
- Run lcov.
lcov -o coverage.info -c -d src
- Run genhtml to generate HTML report
genhtml -o result coverage.info
- Finally go into the result directory and check the HTML report with your browser.
We also have a web coverage service plugged in our Continuous Integration service, that automatically does all of this. You can go on Coveralls.io and watch the Denemo report. Note that it only covers tests ran on Travis, so it may not be very representative of the whole Denemo coverage state. For example, tests are ran on non interactive mode, so GUI related code is ignored.
The first step to do is install jhbuild and all of its dependencies. These are specific platform specific documentation that you will probably have to read to get this going:
- Mac Os X – Go here and to find what needs to be done to build jhbuild on your platform
- Windows – Mingw Native Build
- Linux – The manual mentioned above is sufficient.
You will need to edit your .jhbuildrc-custom mentioned in the jhbuild manual. These additional lines will need to be added:
build_policy = "updated-deps" moduleset=os.path.join(os.environ "HOME", "Source", "jhbuild", "modulesets", "gtk-osx-build.modules") moduleset = 'denemo.modules'
The build_policy tells it not to rebuild things if they have already been built. The first moduleset tells jhbuild to use the local modulesets instead of downloading them eachtime. This make it easier to modify them if we need to.
Save this as jhbuild/modulesets/denemo.modules in your jhbuild source directory.
The directory names may need adjusting. Then you are going to start compiling denemo and its dependencies:
jhbuild build denemo
Note: This still has some dependencies to be added to compile. This is a work in progress. (Contributions are always welcome).
You may get those errors trying to compile libgcrypt:
-fno-common -DPIC -o .libs/mpih-add1-asm.o mpih-add1-asm.S:47:suffix or operands invalid for `push' mpih-add1-asm.S:48:suffix or operands invalid for `push' mpih-add1-asm.S:78:suffix or operands invalid for `jmp' mpih-add1-asm.S:113:suffix or operands invalid for `pop' mpih-add1-asm.S:114:suffix or operands invalid for `pop' make2: *** mpih-add1-asm.lo Error 1 make1: *** all-recursive Error 1 make: *** all Error 2
If you drop to shell using the menu you can configure it manually with something like this:
../configure prefix /Users/jjbenham/gtk/inst libdir ‘/Users/jjbenham/gtk/inst/lib’ –disable-asm
ctrl-d will exit the shell. Then rerun phase build. It should continue after this.
You may have to manually run configure and add –disable-xlib to the arguments
You may have to append this to configure –with-authfw=shadow
If you have gtk-doc installed, you can build the denemo sources reference. Just run the following command and check out docs/reference/denemo/html:
../configure --enable-gtk-doc && make -C docs/reference/denemo
If you want to print a message in the console, there are several log levels, and several cases to use them. To print a message with the log level XXX you can use the function g_XXX(…) in C, and the function (d-XXX) in Scheme. Both functions takes the same parameters than printf.
Here are the different log levels:
- debug: Information useful to developers. You should compile with -DDEBUG (i.e. use ../configure ‐‐enable-debug) and use ‐‐verbose to see debug messages.
- info: Information usually uninteresting for users, but may help the user to report a bug. You need to use ‐‐verbose to see info messages.
- message: Regular messages, interesting for users (e.g. “Portmidi initialized”)
- warning: Unwanted but not dramatic stuff (e.g. “could not load foobar.denemo”)
- critical: Not dramatic stuff, it should not kill the program, but it should make tests fail (e.g. invalid scheme function use)
- error: Dramatic error, kills the program.
Functions that print directly on the standard and error output, like print_f or g_print, should be avoided as much as possible.