CMake, CTest, and AVOGADRO_PLUGIN

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)

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! :slight_smile:

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?

Dave

27.05.10, 16:20, “David Lonie” loniedavid@gmail.com:

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 )

set (xtalopt_UIS )

avogadro_plugin(xtalopt
"{xtalopt_SRCS}" "{xtalopt_UIS}"
)

target_link_libraries(xtalopt QPlotWidget)

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! :slight_smile:

Link your stuff into static library, and use it in both targets
Alternatively you may write custom Makefile :slight_smile:

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?

Yes, and probably on Widows too

Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

2010/5/27 Konstantin Tokarev annulen@yandex.ru:

Link your stuff into static library, and use it in both targets

Is there a way to do this and still use the avogadro_plugin macro?

27.05.10, 18:22, “David Lonie” loniedavid@gmail.com:

2010/5/27 Konstantin Tokarev :

Link your stuff into static library, and use it in both targets

Is there a way to do this and still use the avogadro_plugin macro?

You can use avogadro_plugin macro for those files you don’t need for test. Others add to static library and use target_link_libraries to add your library into plugin. The same for test executable


Regards,
Konstantin

On Thu, May 27, 2010 at 10:25 AM, Konstantin Tokarev annulen@yandex.ru wrote:

27.05.10, 18:22, “David Lonie” loniedavid@gmail.com:

2010/5/27 Konstantin Tokarev :

Link your stuff into static library, and use it in both targets
Is there a way to do this and still use the avogadro_plugin macro?
You can use avogadro_plugin macro for those files you don’t need for test. Others add to static library and use target_link_libraries to add your library into plugin. The same for test executable

Ok – I’m definitely making progress, but now I’ve got some problems
with moc’ing the headers. I’ve pulled the relevant bits from
avogadro_plugin to moc the headers via:

function(moc_qt_headers src_list moc_list)

Assume all MOC stuff is in the headers, replace .cpp and use qt4_wrap_cpp

We should probably scan the header to verify the Q_OBJECT macro is used

string(REPLACE “.cpp” “.h” hdr_list "{src_list}") qt4_wrap_cpp(moc_files {hdr_list})
set( {moc_list} {moc_files} PARENT_SCOPE)
endfunction(moc_qt_headers)

and then running as so:

set( generic_SRCS )

moc_qt_headers("{generic_SRCS}" generic_MOCS) add_library(globalsearch STATIC {generic_SRCS} {generic_MOCS}) target_link_libraries( globalsearch {LINK_LIBS}
{QT_QTCORE_LIBRARY} {QT_QTGUI_LIBRARY}
${OPENBABEL2_LIBRARIES}
avogadro)

Trouble is, the function I’m using is writing the moc files as
moc_filename.cxx instead of filename.moc, which is what
avogadro_plugin produces and my code expects. I can’t locate the bit
of cmake magic that renames them – any ideas?

Dave

There was qt4_automoc(), didn’t you try it?

27.05.10, 19:40, “David Lonie” loniedavid@gmail.com:

On Thu, May 27, 2010 at 10:25 AM, Konstantin Tokarev wrote:

27.05.10, 18:22, “David Lonie” :

2010/5/27 Konstantin Tokarev :

Link your stuff into static library, and use it in both targets
Is there a way to do this and still use the avogadro_plugin macro?
You can use avogadro_plugin macro for those files you don’t need for test. Others add to static library and use target_link_libraries to add your library into plugin. The same for test executable

Ok – I’m definitely making progress, but now I’ve got some problems
with moc’ing the headers. I’ve pulled the relevant bits from
avogadro_plugin to moc the headers via:

function(moc_qt_headers src_list moc_list)

Assume all MOC stuff is in the headers, replace .cpp and use qt4_wrap_cpp

We should probably scan the header to verify the Q_OBJECT macro is used

string(REPLACE “.cpp” “.h” hdr_list "{src_list}") qt4_wrap_cpp(moc_files {hdr_list})
set( {moc_list} {moc_files} PARENT_SCOPE)
endfunction(moc_qt_headers)

and then running as so:

set( generic_SRCS )

moc_qt_headers("{generic_SRCS}" generic_MOCS) add_library(globalsearch STATIC {generic_SRCS} {generic_MOCS}) target_link_libraries( globalsearch {LINK_LIBS}
{QT_QTCORE_LIBRARY} {QT_QTGUI_LIBRARY}
${OPENBABEL2_LIBRARIES}
avogadro)

Trouble is, the function I’m using is writing the moc files as
moc_filename.cxx instead of filename.moc, which is what
avogadro_plugin produces and my code expects. I can’t locate the bit
of cmake magic that renames them – any ideas?

Dave


Regards,
Konstantin

Здесь спама нет http://mail.yandex.ru/nospam/sign

Also, you go ahead with those moc_*.cxx files - just remove #includes

27.05.10, 19:40, “David Lonie” loniedavid@gmail.com:

On Thu, May 27, 2010 at 10:25 AM, Konstantin Tokarev wrote:

27.05.10, 18:22, “David Lonie” :

2010/5/27 Konstantin Tokarev :

Link your stuff into static library, and use it in both targets
Is there a way to do this and still use the avogadro_plugin macro?
You can use avogadro_plugin macro for those files you don’t need for test. Others add to static library and use target_link_libraries to add your library into plugin. The same for test executable

Ok – I’m definitely making progress, but now I’ve got some problems
with moc’ing the headers. I’ve pulled the relevant bits from
avogadro_plugin to moc the headers via:

function(moc_qt_headers src_list moc_list)

Assume all MOC stuff is in the headers, replace .cpp and use qt4_wrap_cpp

We should probably scan the header to verify the Q_OBJECT macro is used

string(REPLACE “.cpp” “.h” hdr_list "{src_list}") qt4_wrap_cpp(moc_files {hdr_list})
set( {moc_list} {moc_files} PARENT_SCOPE)
endfunction(moc_qt_headers)

and then running as so:

set( generic_SRCS )

moc_qt_headers("{generic_SRCS}" generic_MOCS) add_library(globalsearch STATIC {generic_SRCS} {generic_MOCS}) target_link_libraries( globalsearch {LINK_LIBS}
{QT_QTCORE_LIBRARY} {QT_QTGUI_LIBRARY}
${OPENBABEL2_LIBRARIES}
avogadro)

Trouble is, the function I’m using is writing the moc files as
moc_filename.cxx instead of filename.moc, which is what
avogadro_plugin produces and my code expects. I can’t locate the bit
of cmake magic that renames them – any ideas?

Dave


Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

2010/5/27 Konstantin Tokarev annulen@yandex.ru:

Also, you go ahead with those moc_*.cxx files - just remove #includes

That seems to be working – I think we used to need them, and I didn’t
notice the change.

Still, it’s strange that avogadro_plugin produces .moc while my
function produce moc_
.cxx, since it’s pretty much copy/pasted :slight_smile:

Thanks,
Dave

Ok, I found part of the problem – I was referring to the
avogadro_plugin function in libavogadro/CMakeLists.txt instead of the
one in AvogadroUse.cmake. That explains the difference between the
moc’d header (one uses qt4_wrap_cpp, the other uses qt4_automoc).

I did manage to get the code to compile as separate libraries, but
there’s still a problem: I have tons of undefined symbols in my final
.so file. I hate to be such a bother, but I’m really quite
inexperienced with setting up build systems. If someone could glance
through my CMakeLists.txt file and let me know if there’s anything
obviously wrong with it, I’ll be very grateful :slight_smile:

I’ve dumped a copy of it here: http://codepad.org/6ZPZQQN9

Here’s what I /intended/ to do…

  1. Build a static libglobalsearch.a with some generic functions
  2. Build static libspglib.a containing the spglib code from Atsushi Togo
  3. Build the final xtalopt.so module, linked with the above two static libs.

I can’t see my mistake, perhaps a more experienced set of eyes can catch it?

Thanks again,
Dave

27.05.10, 21:37, “David Lonie” loniedavid@gmail.com:

Ok, I found part of the problem – I was referring to the
avogadro_plugin function in libavogadro/CMakeLists.txt instead of the
one in AvogadroUse.cmake. That explains the difference between the
moc’d header (one uses qt4_wrap_cpp, the other uses qt4_automoc).

I did manage to get the code to compile as separate libraries, but
there’s still a problem: I have tons of undefined symbols in my final
.so file. I hate to be such a bother, but I’m really quite
inexperienced with setting up build systems. If someone could glance
through my CMakeLists.txt file and let me know if there’s anything
obviously wrong with it, I’ll be very grateful :slight_smile:

I’ve dumped a copy of it here: http://codepad.org/6ZPZQQN9

Maybe you’ve linked some stuff twice? E.g., I’m sure avogadro_plugin links Qt and GL libraries

Anyway, it would be better if you posted here full linking command

Here’s what I /intended/ to do…

  1. Build a static libglobalsearch.a with some generic functions
  2. Build static libspglib.a containing the spglib code from Atsushi Togo
  3. Build the final xtalopt.so module, linked with the above two static libs.

I can’t see my mistake, perhaps a more experienced set of eyes can catch it?

Thanks again,
Dave


Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

About Spglib: I think this is what we could use for symmetry support inside Avogadro. So, it’ll be probably reasonable to make it our external dependency, available for all extensions, or include C++ wrapper into API

27.05.10, 21:37, “David Lonie” loniedavid@gmail.com:

Ok, I found part of the problem – I was referring to the
avogadro_plugin function in libavogadro/CMakeLists.txt instead of the
one in AvogadroUse.cmake. That explains the difference between the
moc’d header (one uses qt4_wrap_cpp, the other uses qt4_automoc).

I did manage to get the code to compile as separate libraries, but
there’s still a problem: I have tons of undefined symbols in my final
.so file. I hate to be such a bother, but I’m really quite
inexperienced with setting up build systems. If someone could glance
through my CMakeLists.txt file and let me know if there’s anything
obviously wrong with it, I’ll be very grateful :slight_smile:

I’ve dumped a copy of it here: http://codepad.org/6ZPZQQN9

Here’s what I /intended/ to do…

  1. Build a static libglobalsearch.a with some generic functions
  2. Build static libspglib.a containing the spglib code from Atsushi Togo
  3. Build the final xtalopt.so module, linked with the above two static libs.

I can’t see my mistake, perhaps a more experienced set of eyes can catch it?

Thanks again,
Dave


Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

2010/5/27 Konstantin Tokarev annulen@yandex.ru:

27.05.10, 21:37, “David Lonie” loniedavid@gmail.com:

I did manage to get the code to compile as separate libraries, but
there’s still a problem: I have tons of undefined symbols in my final
.so file. I hate to be such a bother, but I’m really quite
inexperienced with setting up build systems. If someone could glance
through my CMakeLists.txt file and let me know if there’s anything
obviously wrong with it, I’ll be very grateful :slight_smile:

I’ve dumped a copy of it here: http://codepad.org/6ZPZQQN9

Maybe you’ve linked some stuff twice? E.g., I’m sure avogadro_plugin links Qt and GL libraries

Anyway, it would be better if you posted here full linking command

Here it is:

/usr/bin/c++ -fPIC -g -shared -Wl,-soname,xtalopt.so -o xtalopt.so
CMakeFiles/xtalopt.dir/src/extension.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/xtalopt.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/genetic.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/optimizers/xtaloptoptimizer.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/optimizers/vasp.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/optimizers/gulp.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/optimizers/pwscf.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/testing/xtalopttest.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/dialog.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_init.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_edit.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_opt.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_sys.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_progress.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_plot.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_log.cpp.o
-lAvogadroCore -lAvogadroWidget -lQtCore -lQtGui -lopenbabel
-lQPlotWidget libglobalsearch.a libspglib.a -lavogadro -lAvogadroCore
-lopenbabel -lQtOpenGL -lQtCore -lQtGui -lGLU -lGL -lSM -lICE -lX11
-lXext

Ah, some things did get linked twice. I’ve updated the CMakeLists to
eliminate that problem, but the undefined symbols are still there.

I took a closer look, and all of the undefined symbols are vtables and
signals. Could be a problem with moc’ing? I noticed that the
avogadro_plugin function in the use file doesn’t pass the moc files to
the add_library function. I don’t know if this is a problem or not –
qt4_automoc seems to be poorly documented.

Dave

2010/5/27 Konstantin Tokarev annulen@yandex.ru:

About Spglib: I think this is what we could use for symmetry support inside Avogadro. So, it’ll be probably reasonable to make it our external dependency, available for all extensions, or include C++ wrapper into API

I wouldn’t recommend making it a dependency – it’s sort of a pain to
install (IIRC there is no “make install” target, the files must be
installed manually).

However, it is GPL and the author is friendly – it should be simple
to add it to openbabel. I’ve been meaning to try this for a while, but
time gets short.

It’s pretty reliable, my only complaint is that it uses fractional
tolerances, which is annoying when working with oddly shaped cells
(say 20x20x5).

Dave

27.05.10, 22:08, “David Lonie” loniedavid@gmail.com:

2010/5/27 Konstantin Tokarev :

27.05.10, 21:37, “David Lonie” :

I did manage to get the code to compile as separate libraries, but
there’s still a problem: I have tons of undefined symbols in my final
.so file. I hate to be such a bother, but I’m really quite
inexperienced with setting up build systems. If someone could glance
through my CMakeLists.txt file and let me know if there’s anything
obviously wrong with it, I’ll be very grateful :slight_smile:

I’ve dumped a copy of it here: http://codepad.org/6ZPZQQN9

Maybe you’ve linked some stuff twice? E.g., I’m sure avogadro_plugin links Qt and GL libraries

Anyway, it would be better if you posted here full linking command

Here it is:

/usr/bin/c++ -fPIC -g -shared -Wl,-soname,xtalopt.so -o xtalopt.so
CMakeFiles/xtalopt.dir/src/extension.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/xtalopt.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/genetic.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/optimizers/xtaloptoptimizer.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/optimizers/vasp.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/optimizers/gulp.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/optimizers/pwscf.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/testing/xtalopttest.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/dialog.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_init.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_edit.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_opt.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_sys.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_progress.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_plot.cpp.o
CMakeFiles/xtalopt.dir/src/xtalopt/ui/tab_log.cpp.o
-lAvogadroCore -lAvogadroWidget -lQtCore -lQtGui -lopenbabel
-lQPlotWidget libglobalsearch.a libspglib.a -lavogadro -lAvogadroCore
-lopenbabel -lQtOpenGL -lQtCore -lQtGui -lGLU -lGL -lSM -lICE -lX11
-lXext

Ah, some things did get linked twice. I’ve updated the CMakeLists to
eliminate that problem, but the undefined symbols are still there.

I took a closer look, and all of the undefined symbols are vtables and
signals. Could be a problem with moc’ing?

Looks like it is.

I noticed that the
avogadro_plugin function in the use file doesn’t pass the moc files to
the add_library function. I don’t know if this is a problem or not –
qt4_automoc seems to be poorly documented.

Dave


Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

I took a closer look, and all of the undefined symbols are vtables and
signals. Could be a problem with moc’ing?

Looks like it is.

Aha – I took out the moc includes when using qt4_wrap_cpp, but
automoc expects them to be there. Seems to be working now :slight_smile:

BTW, is there a reason that MODULE is used instead of SHARED for the plugins?

Dave

BTW, is there a reason that MODULE is used instead of SHARED for the plugins?

  1. It doesn’t add “lib-” prefix to output (but there’s no difference actually)
  2. Nothing can be linked to MODULE in CMake project
  3. Separate set of flags could be set for modules in CMake


Regards,
Konstantin

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! :slight_smile:

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

On Thursday 27 May 2010 15:56:24 Konstantin Tokarev wrote:

BTW, is there a reason that MODULE is used instead of SHARED for the
plugins?

  1. It doesn’t add “lib-” prefix to output (but there’s no difference
    actually)

It does add a lib prefix, I removed the prefix for our plugins using a target
property…

  1. Nothing can be linked to MODULE in CMake project
  2. Separate set of flags could be set for modules in CMake

Yep - plugins are modules. They tend to be very thin. If you have a lot in
your plugins, then perhaps consider moving some of this into a lib rather than
putting it all in a plugin? Alternatively, make your plugin a library - should
still load without issue.

Marcus

Hi Marcus,

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).

I copied avogadro_plugin into my CMakeLists.txt and changed MODULE to
SHARED, ran all the extension sources through it, then linked the
plugin target to the test target – works a treat!

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.

Ah, ok. That clears up some of my questions about that.

Thanks,

Dave

I copied avogadro_plugin into my CMakeLists.txt and changed MODULE to
SHARED, ran all the extension sources through it, then linked the
plugin target to the test target – works a treat!

I don’t understand, why this thing matters - nothing could be linked to module, but (AFAIK) module could be linked to everything you want…

Regards,
Konstantin