On Thursday 27 May 2010 08:20:15 David Lonie wrote:
Hi all,
I’ve started using CTest to run tests on my extension, but there is a
snag. My CMakeLists has this:
Build your plugin using the default options
set (xtalopt_SRCS <list of .cpp files>)
set (xtalopt_UIS <list of .ui files>)
avogadro_plugin(xtalopt
“{xtalopt_SRCS}"
"{xtalopt_UIS}”
)
target_link_libraries(xtalopt QPlotWidget)
You probably want avogadro back as the link lib now… You could safely make
it a shared library (we used to do this), and it should still be loaded by
Avogadro properly. Your other option is to split out most of what you want
into a shared library, and link to that from the plugin and your tests…
enable_testing()
add_executable(checkTemplates {xtalopt_SRCS} tests/checkTemplates.cpp)
target_link_libraries(checkTemplates {LINK_LIBS} {QT_QTCORE_LIBRARY}
{QT_QTGUI_LIBRARY} ${OPENBABEL2_LIBRARIES} avogadro QPlotWidget)
add_test(TemplateCheck checkTemplates)
When I run make on this, all the cpp files in xtalopt_SRCS are
compiled twice, once for target xtalopt, and again for target
checkTemplates. Is there a way to tell CMake to reuse the object files
for both? Surely I don’t have to double my compilation time by adding
a test! 
This comes up a lot. The options are to create a static library, and link to
it from several places, factor the common stuff out into a shared (or static)
library, and link to that from the places you want to use it. You can also use
things like ccache.
I’ve also tried changing it to
add_executable(checkTemplates tests/checkTemplates.cpp)
target_link_libraries(checkTemplates {LINK_LIBS} {QT_QTCORE_LIBRARY}
{QT_QTGUI_LIBRARY} {OPENBABEL2_LIBRARIES} avogadro QPlotWidget
xtalopt)
to try linking the xtalopt.so file, but this didn’t work, as CMake
sees xtalopt as a “module”, and not a “shared library”, though AFAIK
these are the same on linux, correct?
They are the same on Linux, and so if I were you I would probably explore
making it shared. We did this for quite a while in Avogadro before I changed
it to module (as that is what a plugin is).
You ran into the automoc/wrap_cpp logic too - I should harmonize that. The
advantage of wrap_cpp is that it generates a list of moc source files, and you
can use the build system to link them in. With automoc it guesses what the file
should be called, and then creates it.
Essentially they both do the same thing in the end, one passes extra source
files into the build system, the other requires a direct include in your source
file.
Is that clearer? Don’t always get chance to check this list at work, and today
was especially hectic.
Marcus
