libshv won't build Qt-based libs, if the Qt dependencies aren't met. shvspy has different Qt dependencies, so they could be met even if libshv's aren't. This could mean that the libshv::libshvvisu target doesn't get created. CMake correctly recognizes this as an error when trying to link this target, but unfortunately creates a non-working Makefile anyway. Users who ignore the errors and try to use this Makefile might get confused as to why shvpsy doesn't build.
The solution is to explicitly check for the libshv::libshvvisu target, and erroring out if it doesn't exist. No Makefile is generated this way.
The other solution would be to add a flag to libshv that would force libshv to make the Qt-based libs and produce an error, if it can't. However, this change would really only be useful for projects that consume libshv as a submodule, which is very common, but still not the "right" usage. I'd rather not put extra code into libshv for that.
syyyr
commented
5 months ago
libshv won't build Qt-based libs, if the Qt dependencies aren't met. shvspy has different Qt dependencies, so they could be met even if libshv's aren't. This could mean that the
libshv::libshvvisutarget doesn't get created. CMake correctly recognizes this as an error when trying to link this target, but unfortunately creates a non-working Makefile anyway. Users who ignore the errors and try to use this Makefile might get confused as to why shvpsy doesn't build.The solution is to explicitly check for the
libshv::libshvvisutarget, and erroring out if it doesn't exist. No Makefile is generated this way.The other solution would be to add a flag to libshv that would force libshv to make the Qt-based libs and produce an error, if it can't. However, this change would really only be useful for projects that consume libshv as a submodule, which is very common, but still not the "right" usage. I'd rather not put extra code into libshv for that.