Linking with DBUILD_AS_PLUGINS=1 fails

[TBRTechSAT]

....
[ 75%] Building CXX object src/uscxml/plugins/ioprocessor/CMakeFiles/ioproc_basichttp.dir/__/Plugins.cpp.o
Linking CXX shared library ../../../../lib/plugins/libioproc_basichttp.so
CMakeFiles/ioproc_basichttp.dir/http/HTTPIOProcessor.cpp.o: In function `pluginConnect':
/var/lib/jenkins/workspace/uscxml-CentOS7/uscxml/src/uscxml/plugins/ioprocessor/http/HTTPIOProcessor.cpp:55: multiple definition of `pluginConnect'
CMakeFiles/ioproc_basichttp.dir/basichttp/BasicHTTPIOProcessor.cpp.o:/var/lib/jenkins/workspace/uscxml-CentOS7/uscxml/src/uscxml/plugins/ioprocessor/basichttp/BasicHTTPIOProcessor.cpp:51: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [lib/plugins/libioproc_basichttp.so] Error 1
make[1]: *** [src/uscxml/plugins/ioprocessor/CMakeFiles/ioproc_basichttp.dir/all] Error 2
make: *** [all] Error 2
Build step 'Execute shell' marked build as failure
Finished: FAILURE

[sradomski]

I am afraid that building with plugins is still very much experimental due to the missing ABI specification of C++. It used to work with llvm and gcc, but was always rather fragile. I am more inclined to drop the feature than to support it.

[TBRTechSAT]

I find the use of plugins very well suited to the dynamic execution of SCXML script. If I have to handle a new custom feature in SCXML (invoker, datamodel...), I prefer to only compile and distribute an additional plugin. The missing ABI spec for C++ is not a problem for me because I will create a plugin for a specific target (OS + architecture + compiler).