Better test macro support for 3rd-party components

[ohhmm]

Better test macro support for 3rd-party components

[devin-ai-integration]

Issue: Overwriting a cached variable

In CMakeLists.txt, you're setting BOOST_TEST_LINK_LIBS as a cached variable with FORCE and then immediately overwriting it:

set(BOOST_TEST_LINK_LIBS ${BOOST_TEST_LINK_LIBS} CACHE STRING "Boost test libraries" FORCE)
add_library(testlibs INTERFACE)
target_link_libraries(testlibs INTERFACE ${BOOST_TEST_LINK_LIBS})
set(BOOST_TEST_LINK_LIBS testlibs)

This pattern can lead to unexpected behavior since the cached value is immediately discarded. Consider either:

1. Creating a new variable for the testlibs target instead of reusing BOOST_TEST_LINK_LIBS
2. Or setting the cache variable after the modification: set(BOOST_TEST_LINK_LIBS testlibs CACHE STRING "Boost test libraries" FORCE)

[devin-ai-integration]

Issue: Redundant library linking

In cmake/bins.cmake, you're adding a line to link the testlibs library to each test target:

target_link_libraries(${TEST_NAME} PUBLIC testlibs)

However, the test function already links BOOST_TEST_LINK_LIBS (which now points to testlibs) in lines 336-337 for non-MSVC or OPENMIND_USE_CONAN builds:

if(NOT MSVC OR OPENMIND_USE_CONAN)
    message("NOT MSVC OR OPENMIND_USE_CONAN, using deps ${BOOST_TEST_LINK_LIBS}")
    deps(${BOOST_TEST_LINK_LIBS})
endif()

This creates a redundant linking situation where testlibs could be linked twice. Consider either:

1. Removing the new link statement and letting the existing code handle it
2. Or modifying the existing code to avoid the redundancy

[devin-ai-integration]

Issue: Platform-specific code improvements

I notice you've made two related changes to improve Windows platform support:

1. Added pragma comment in omnn/math/test/08_System.cpp:

#ifdef _WIN32
#pragma comment(lib, "User32.lib") // EnableMenuItem / GetSystemMenu
#endif // _WIN32

2. Removed explicit target_link_libraries in omnn/math/test/CMakeLists.txt:

target_link_libraries(08_System PUBLIC
	$<$<PLATFORM_ID:Windows>:User32>
)

While this change makes sense as part of improving test macro support, it would be helpful to add a comment in the PR description explaining why the pragma approach is preferred over the CMake generator expression approach. This would help reviewers understand the rationale behind this specific change.

[devin-ai-integration]

Everything looks good! The issues have already been identified in previous comments.

[devin-ai-integration]

Everything looks good! The issues have already been identified in previous comments.