Open jpola opened 9 years ago
Give me a day or two to brainstorm :crystal_ball:
The complicated part of testing internal routines, is that we normally compile our library as a dynamic shared module, and it does not export routines unless they are decorated with CLSPARSE_EXPORT.
That leaves two options available on the table:
Hi, what I would like to have is to take part of the clSPARSE (internal data structures, kernel mechanism execution and probably other existing algorithms and put it nicely into one "internal" test which helps to develop other algorithms. Here I want to avoid linking with the clSPARSE library, it can be broken in some places during the development. Is that idea is described in second point of your script (Forgive me I didn't understand what you have written there)?
2015-09-08 7:42 GMT+02:00 Kent Knox notifications@github.com:
The complicated part of testing internal routines, is that we normally compile our library as a dynamic shared module, and it does not export routines unless they are decorated with CLSPARSE_EXPORT.
That leaves two options available on the table:
- We write internal test programs that MUST link to the library as a STATIC module, or the linker will complain of unresolved symbols
- We write internal test programs that compile in bits of the library we want to internally test, i.e. it includes as part of the test executable files from the library. In this way, the test program avoids linking in the library altogether.
— Reply to this email directly or view it on GitHub https://github.com/clMathLibraries/clSPARSE/issues/137#issuecomment-138440346 .
Yes, so I think either of the two options I listed above would work, and I am leaving it open to see which way you would prefer. To explain in more detail:
This issue emerged with #135. @shuaiche and me have to develop several internal algorithms. Since new algorithms will be more complex it will be very useful to develop a test infrastructure which helps to easily validate and debug internal clSPARSE algorithms. Nowadays I did that by adding temporary interface API functions in clSPARSE.h but that is very time consuming and it is limited with C language restrictions.
Do you have any ideas how to tackle this issue? Where to put new test-internal folder? How the project tree should look like?
What is your experience with that?