testing framework

[xflouris]

Please add a wiki documentation section with the steps on how to run the testing framework. It's always a painful thing to make it run, especially with the increasing number of header files.

[ddarriba]

make && ./runtest.py should work. What is the problem exactly?

[xflouris]

I need to be adding -L to CFLAGS, -I for the header files, and modify C files for the correct include paths (for example pll_tree.c points to a wrong pll.h path).

Do you have some easier way (like specifying some env variable before make) or you also manually change CFLAGS?

[ddarriba]

I install the library. That's why everything is working. pll_tree (and also pll_optimize) should include "pll.h" instead of <pll.h> (fixed)

I added CPPFLAGS to the Makefile, so you can use make CPPFLAGS="-I... -L..."

[amkozlov]

I also think there should be an easier way to compile/run the examples, also without installing the library system-wide. Could we:

• have a single env variable PLL_ROOT which could be exported and then used in Makefile
• even better: extract library root path from the directory where examples are located (I simply set relative path in Makefiles to make it work)

?

Are there are actually any usecases where you'd want to use system-wide libpll for building examples, and not the one in the same directory?

[xflouris]

thanks! now it works fine with

export LD_LIBRARY_PATH=$PWD/../src CPPFLAGS="-I../src -L../src" make

Can you add it as a section 'Testing' in https://github.com/xflouris/libpll/wiki/Contributing-to-libpll when you have time, such that we can refer to it quickly anytime we want to run the test?

Can you do the same fix (with CPPFLAGS) for the Makefile.w64? Also, it is not clear yet what eval_valgrind.sh does (for me it prints 0 0 0 0).

[xflouris]

@amkozlov : probably @ddarriba has some usecase with modeltest. At the moment I prefer not having a system-wide libpll, bur rather build the library and refer to the object manually. Modifying the example Makefiles to point to the src dir is possible, but I'd avoid it as this can be done with env variables, and especially when testing different versions of the library, env vars come handy.

When the library gets more stable we'll have a build system.

[amkozlov]

OK, then let's have a "build.sh" script which contains the above lines. This will prevent confusion and doing the monkey job every time.

[xflouris]

I think it's okay if everyone keeps his own build.sh locally; no need to enforce a particular way, as long as an example (like the one above) is written in th README.md and accessible to all.