On 07.06.21 19:27, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
On 6/7/21 7:48 PM, John Maddock via Boost wrote:
On 07/06/2021 17:26, Peter Dimov via Boost wrote:
Edward Diener wrote:
Since it is totally legitimate to use Boost.Test in header only mode, and many libraries currently do this, it is hardly a "waste of time" to support this under CMake.
Under CMake you can't use header-only libraries without linking to their targets. So there's no real benefit from having a separate header-only target to link to; you can just link to the ordinary target Boost::unit_test_framework.
Doesn't that a) cause the unit test lib to be build when it doesn't need to be, and b) add the resulting binary to library link list when it doesn't need to be?
But I do appreciate the simplicity of a single target ;)
Another question is whether unnecessarily linking would cause duplicate symbols or ODR issues. I believe, you're not supposed to use header-only Boost.Test and then link against it, too, as the same symbols would be defined both in the test and the library.
It works because the symbols in the executable override those in libraries, but it's indeed not quite right in principle.
Hi all, I am skeptical about this: * the overriding behaviour sounds to me system dependent, * we may duplicate some of the singletons, * some compilation information may be different between the build time and the consumption time of the library. The 2 steps build (library generation with one set of options, header only consumption with potentially another set of options) may create difficult to debug situations. I would avoid this.
Boost.Test could define two sets of targets - one for header-only and the other for separately built library. One benefit of that is that you could use different macros for these two targets, if needed (e.g. if the library sources need to discriminate between the two configs).
That's probably what we'll have to do, yes.
Any input from the Boost.Test maintainer? Raffi?
I believe the correct way to do that in the CMake world is to use an INTERFACE library, as it carries the include folder, compiler options, defines etc together with the target cmake object, without actually building anything, and that is what we need for header only: https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#interfac... I have not looked at the recent developments for CMake in Boost. If the CMakeLists.txt I developed (under build/) is still there, it contained 2 targets: one for static and one for shared. Those were having different and explicit names. Having a 3rd target for header only sounds good to me. I can give a go if you want. Raffi PS.: for those hitting the deprecated API... it's been deprecated since almost a decade now :)