Skip to content

Conversation

@nyoma-diamond
Copy link

Resolves #3125, where building dlib using one compiler or system and linking to a consumer using a different one is incompatible.

Key changes:

  • Changed some calls to target_compile_options and target_compile_features from PUBLIC to PRIVATE, preventing dlib's compile-time configuration forcing incorrect assumptions on the consumer.
    • active_compile_opts
    • dlib_needed_public_cflags (now named dlib_needed_private_cflags)
    • dlib_needed_public_ldflags (now named dlib_needed_private_ldflags)
  • Combined active_compile_opts and active_compile_opts_private (the latter no longer needs to be a separate variable)
  • Applying active_compile_opts no longer requires different methodologies depending on if MSVC + CMake < 3.11 are used (simpler approach)

@nyoma-diamond nyoma-diamond marked this pull request as ready for review December 23, 2025 13:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: dlib binaries/targets built via MSVC cause error when consumed via clang[++]: no such file or directory: '/bigobj'

1 participant