Closed diegoferigo closed 5 years ago
Thanks for the link! target_sources
always puzzled me and before reading that post I found it useful just for header-only libraries.
I tried to change this PR to use target_sources
but I even if it allowed using add_blockfactory_plugin
at a high hierarchy, and then call add_blockfactory_block
from subdirectories (which might be useful), this approach has some flaws. Using target_link_libraries
is quite difficult with CMake < 3.13, and the constraint of hardcoding ${CMAKE_CURRENT_LIST_DIR}
is a no-go in my opinion.
If it can improve the readability, what about renaming add_blockfactory_block
to register_blockfactory_block
? I can drop a comment in the file to evaluate again the method you proposed when we will support CMake 3.13.
If it can improve the readability, what about renaming
add_blockfactory_block
toregister_blockfactory_block
?
Ok both alternatives for me, target_sources
was just just a suggestion, I do not think it is a blocking problem the order of add_blockfactory_block
and add_blockfactory_plugin
.
I will keep register_blockfactory_block
, it is more descriptive of what it actually does.
Two new CMake functions are included:
They can be used by downstream projects for creating the plugin library. They will substitute the logic of configure_block.