Closed peter-t-fox closed 11 months ago
Hi Peter,
Well, that's not a good user experience for sure, thank you for reporting it!
Yes, it is kind of a msgpack problem, but I've decided that I'm responsible for my dependencies, so it is also a MUSCLE3 problem. I think the best solution is to just skip building the msgpack tests, since we're trying to use it, not test it.
I'll add this fix in the next release, thank you!
The fix for this was included in 0.7.0, so it should work out of the box now. If that fixes it, could you close this issue?
@peter-t-fox, since you probably didn't get notified of this one either. There's no hurry, whenever is convenient for you is fine.
@LourensVeen Apologies for the delay, I don't seem to get any notifications at all. We are now using MUSCLE3 v0.7.0 and the build works perfectly without any hacking of the msgpack
build. Thanks for resolving this!
I am trying to build MUSCLE3 and have run into a problem with its use of
googletest
andmsgpack
.I am building on a cluster where there is an old version of
googletest
installed under/lib64
. When I buildlibmuscle
, it does not find thegoogletest
installation because it is too old and does not provide apkg-config
configuration. And so I get this:This is fine, as I don't want to build the tests. Moreover, since I am not building the
libmuscle
tests
target,googletest
is never downloaded anyway. So far so good.However, when the build of
libmuscle
triggers the build of themsgpack
dependency, the build ofmsgpack
finds the old version ofgoogletest
(via the CMakeFindGTest
facility). The build ofmsgpack
then fails becausegoogletest
is too old, so some of the symbols it needs are out of date. This kills the entirelibmuscle
build.I can work around this problem by setting
-DMSGPACK_BUILD_TESTS=OFF
in the CMake command in themsgpack
target here:However, this obviously requires me to manually edit the MUSCLE3 build sources and maintain that edit in the future, which is not ideal. The alternative is that I separately download and build
msgpack
on my own system, so that I can control whether or not its builds its unit tests. This is probably going to have to be my approach.So I have the question: should MUSCLE3 build the
msgpack
unit tests at all?If yes, maybe it would make sense to arrange the build so that if
googletest
is not found by MUSCLE3, it is downloaded (even for a non-tests build) and that downloaded version ofgoogletest
is also used bymsgpack
, so that everything is consistent?If no (because I guess most/all people using MUSCLE3 are not interested in the
msgpack
unit tests), maybe it would make sense to disable the unit tests as I've done above, and so avoid this kind of problem entirely.(Arguably this is really a
msgpack
problem, as it should maybe download the version ofgoogletest
that it needs, rather than relying on the system to provide it.)