Moved the ODR violation checking code into its own file.

dlib/CMakeLists.txt

@@ -213,6 +213,7 @@ if (NOT TARGET dlib)
          data_io/image_dataset_metadata.cpp
          data_io/mnist.cpp
          global_optimization/global_function_search.cpp
+         all/test_for_odr_violations.cpp
    )
 
 

dlib/all/source.cpp

@@ -19,6 +19,7 @@
 #include "../md5/md5_kernel_1.cpp"
 #include "../tokenizer/tokenizer_kernel_1.cpp"
 #include "../unicode/unicode.cpp"
+#include "test_for_odr_violations.cpp"
 
 
 

dlib/all/test_for_odr_violations.cpp

+// Copyright (C) 2014  Davis E. King (davis@dlib.net)
+// License: Boost Software License   See LICENSE.txt for the full license.
+#ifndef DLIB_TEST_FOR_ODR_VIOLATIONS_CPp_
+#define DLIB_TEST_FOR_ODR_VIOLATIONS_CPp_
+
+#include "test_for_odr_violations.h"
+
+extern "C"
+{
+// The point of this block of code is to cause a link time error that will prevent a user
+// from compiling part of their application with DLIB_ASSERT enabled and part with them
+// disabled since doing that would be a violation of C++'s one definition rule. 
+#ifdef ENABLE_ASSERTS
+    int USER_ERROR__inconsistent_build_configuration__see_dlib_faq_1;
+#else
+    int USER_ERROR__inconsistent_build_configuration__see_dlib_faq_1_;
+#endif
+
+
+// The point of this block of code is to cause a link time error if someone builds dlib via
+// cmake as a separately installable library, and therefore generates a dlib/config.h from
+// cmake, but then proceeds to use the default unconfigured dlib/config.h from version
+// control.  It should be obvious why this is bad, if it isn't you need to read a book
+// about C++.  Moreover, it can only happen if someone manually copies files around and
+// messes things up.  If instead they run `make install` or `cmake --build .  --target
+// install` things will be setup correctly, which is what they should do.  To summarize: DO
+// NOT BUILD A STANDALONE DLIB AND THEN GO CHERRY PICKING FILES FROM THE BUILD FOLDER AND
+// MIXING THEM WITH THE SOURCE FROM GITHUB.  USE CMAKE'S INSTALL SCRIPTS TO INSTALL DLIB.
+// Or even better, don't install dlib at all and instead build your program as shown in
+// examples/CMakeLists.txt
+#ifdef DLIB_NOT_CONFIGURED
+    int USER_ERROR__inconsistent_build_configuration__see_dlib_faq_2;
+#endif
+}
+
+
+#endif // DLIB_TEST_FOR_ODR_VIOLATIONS_CPp_
+

dlib/all/test_for_odr_violations.h

+// Copyright (C) 2014  Davis E. King (davis@dlib.net)
+// License: Boost Software License   See LICENSE.txt for the full license.
+#ifndef DLIB_TEST_FOR_ODR_VIOLATIONS_H_
+#define DLIB_TEST_FOR_ODR_VIOLATIONS_H_
+
+#include "../assert.h"
+#include "../config.h"
+
+extern "C"
+{
+// =========================>>> WHY YOU ARE GETTING AN ERROR HERE <<<=========================
+// The point of this block of code is to cause a link time error that will prevent a user
+// from compiling part of their application with DLIB_ASSERT enabled and part with it
+// disabled since doing that would be a violation of C++'s one definition rule.  So if you
+// are getting an error here then you are either not enabling DLIB_ASSERT consistently
+// (e.g. by compiling part of your program in a debug mode and part in a release mode) or
+// you have simply forgotten to compile dlib/all/source.cpp into your application.
+// =========================>>> WHY YOU ARE GETTING AN ERROR HERE <<<=========================
+#ifdef ENABLE_ASSERTS
+    extern int USER_ERROR__inconsistent_build_configuration__see_dlib_faq_1;
+    inline int dlib_check_consistent_assert_usage() { USER_ERROR__inconsistent_build_configuration__see_dlib_faq_1 = 0; return 0; }
+#else
+    extern int USER_ERROR__inconsistent_build_configuration__see_dlib_faq_1_;
+    inline int dlib_check_consistent_assert_usage() { USER_ERROR__inconsistent_build_configuration__see_dlib_faq_1_ = 0; return 0; }
+#endif
+    const int DLIB_NO_WARN_UNUSED dlib_check_assert_helper_variable = dlib_check_consistent_assert_usage();
+
+
+
+// The point of this block of code is to cause a link time error if someone builds dlib via
+// cmake as a separately installable library, and therefore generates a dlib/config.h from
+// cmake, but then proceeds to use the default unconfigured dlib/config.h from version
+// control.  It should be obvious why this is bad, if it isn't you need to read a book
+// about C++.  Moreover, it can only happen if someone manually copies files around and
+// messes things up.  If instead they run `make install` or `cmake --build .  --target
+// install` things will be setup correctly, which is what they should do.  To summarize: DO
+// NOT BUILD A STANDALONE DLIB AND THEN GO CHERRY PICKING FILES FROM THE BUILD FOLDER AND
+// MIXING THEM WITH THE SOURCE FROM GITHUB.  USE CMAKE'S INSTALL SCRIPTS TO INSTALL DLIB.
+// Or even better, don't install dlib at all and instead build your program as shown in
+// examples/CMakeLists.txt
+#ifdef DLIB_NOT_CONFIGURED 
+    extern int USER_ERROR__inconsistent_build_configuration__see_dlib_faq_2;
+    inline int dlib_check_consistent_config_h_usage() { USER_ERROR__inconsistent_build_configuration__see_dlib_faq_2 = 0; return 0; }
+#else
+    inline int dlib_check_consistent_config_h_usage() { return 0; }
+#endif
+    const int DLIB_NO_WARN_UNUSED dlib_check_not_configured_helper_variable = dlib_check_consistent_config_h_usage();
+
+}
+
+
+
+
+#endif // DLIB_TEST_FOR_ODR_VIOLATIONS_H_
+

dlib/dnn/tensor_tools.h

@@ -13,6 +13,7 @@
 #include "../rand.h"
 #include <memory>
 #include "../geometry/rectangle.h"
+#include "../all/test_for_odr_violations.h"
 
 namespace dlib
 {

dlib/global_optimization/global_function_search.h

@@ -9,6 +9,7 @@
 #include <mutex>
 #include "../rand.h"
 #include "upper_bound_function.h"
+#include "../all/test_for_odr_violations.h"
 
 namespace dlib
 {

dlib/image_loader/jpeg_loader.h

@@ -9,6 +9,7 @@
 #include "image_loader.h"
 #include "../pixel.h"
 #include "../dir_nav.h"
+#include "../all/test_for_odr_violations.h"
 
 namespace dlib
 {

dlib/image_loader/png_loader.h

@@ -9,6 +9,7 @@
 #include "image_loader.h"
 #include "../pixel.h"
 #include "../dir_nav.h"
+#include "../all/test_for_odr_violations.h"
 
 namespace dlib
 {

dlib/threads/threads_kernel_shared.cpp

@@ -8,33 +8,6 @@
 #include "../platform.h"
 #include <iostream>
 
-extern "C"
-{
-// The point of this block of code is to cause a link time error that will prevent a user
-// from compiling part of their application with DLIB_ASSERT enabled and part with them
-// disabled since doing that would be a violation of C++'s one definition rule. 
-#ifdef ENABLE_ASSERTS
-    int USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_use_of_DEBUG_or_ENABLE_ASSERTS_preprocessor_directives;
-#else
-    int USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_use_of_DEBUG_or_ENABLE_ASSERTS_preprocessor_directives_;
-#endif
-
-
-// The point of this block of code is to cause a link time error if someone builds dlib via
-// cmake as a separately installable library, and therefore generates a dlib/config.h from
-// cmake, but then proceeds to use the default unconfigured dlib/config.h from version
-// control.  It should be obvious why this is bad, if it isn't you need to read a book
-// about C++.  Moreover, it can only happen if someone manually copies files around and
-// messes things up.  If instead they run `make install` or `cmake --build .  --target
-// install` things will be setup correctly, which is what they should do.  To summarize: DO
-// NOT BUILD A STANDALONE DLIB AND THEN GO CHERRY PICKING FILES FROM THE BUILD FOLDER AND
-// MIXING THEM WITH THE SOURCE FROM GITHUB.  USE CMAKE'S INSTALL SCRIPTS TO INSTALL DLIB.
-// Or even better, don't install dlib at all and instead build your program as shown in
-// examples/CMakeLists.txt
-#ifdef DLIB_NOT_CONFIGURED
-    int USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_build_configuration;
-#endif
-}
 
 #ifndef DLIB_THREAD_POOL_TIMEOUT
 // default to 30000 milliseconds

dlib/threads/threads_kernel_shared.h

@@ -12,70 +12,7 @@
 #include "../memory_manager.h"
 #include "../queue.h"
 #include "../set.h"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-extern "C"
-{
-// =========================>>> WHY YOU ARE GETTING AN ERROR HERE <<<=========================
-// The point of this block of code is to cause a link time error that will prevent a user
-// from compiling part of their application with DLIB_ASSERT enabled and part with it
-// disabled since doing that would be a violation of C++'s one definition rule.  So if you
-// are getting an error here then you are either not enabling DLIB_ASSERT consistently
-// (e.g. by compiling part of your program in a debug mode and part in a release mode) or
-// you have simply forgotten to compile dlib/all/source.cpp into your application.
-// =========================>>> WHY YOU ARE GETTING AN ERROR HERE <<<=========================
-#ifdef ENABLE_ASSERTS
-    extern int USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_use_of_DEBUG_or_ENABLE_ASSERTS_preprocessor_directives;
-    inline int dlib_check_consistent_assert_usage() { USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_use_of_DEBUG_or_ENABLE_ASSERTS_preprocessor_directives = 0; return 0; }
-#else
-    extern int USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_use_of_DEBUG_or_ENABLE_ASSERTS_preprocessor_directives_;
-    inline int dlib_check_consistent_assert_usage() { USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_use_of_DEBUG_or_ENABLE_ASSERTS_preprocessor_directives_ = 0; return 0; }
-#endif
-    const int DLIB_NO_WARN_UNUSED dlib_check_assert_helper_variable = dlib_check_consistent_assert_usage();
-
-
-
-// The point of this block of code is to cause a link time error if someone builds dlib via
-// cmake as a separately installable library, and therefore generates a dlib/config.h from
-// cmake, but then proceeds to use the default unconfigured dlib/config.h from version
-// control.  It should be obvious why this is bad, if it isn't you need to read a book
-// about C++.  Moreover, it can only happen if someone manually copies files around and
-// messes things up.  If instead they run `make install` or `cmake --build .  --target
-// install` things will be setup correctly, which is what they should do.  To summarize: DO
-// NOT BUILD A STANDALONE DLIB AND THEN GO CHERRY PICKING FILES FROM THE BUILD FOLDER AND
-// MIXING THEM WITH THE SOURCE FROM GITHUB.  USE CMAKE'S INSTALL SCRIPTS TO INSTALL DLIB.
-// Or even better, don't install dlib at all and instead build your program as shown in
-// examples/CMakeLists.txt
-#ifdef DLIB_NOT_CONFIGURED 
-    extern int USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_build_configuration;
-    inline int dlib_check_consistent_config_h_usage() { USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_build_configuration = 0; return 0; }
-#else
-    inline int dlib_check_consistent_config_h_usage() { return 0; }
-#endif
-    const int DLIB_NO_WARN_UNUSED dlib_check_not_configured_helper_variable = dlib_check_consistent_config_h_usage();
-
-}
-
-
-
-
-
-
-
-
-
+#include "../all/test_for_odr_violations.h"