Suggestion for a more explicit `version_string.tmp` filename about opencv HOT 4 OPEN

Hello, I think you can use opencv_verion application instead of this suggestion.

I'm concerned that this will create new discrepancies by separating the library and configuration results files.

If this information is divided into multiple entities, new problems may occur because only part of the information is updated and the rest is outdated.
(Sometimes this problem also occurs between header files and libraries)

So I believe it is better to keep build information in only opencv-library, not external.
And, opencv_version application is helpful to see what configuration is used.

https://github.com/opencv/opencv/blob/4.x/apps/version/opencv_version.cpp

from opencv.

I'm concerned that this will create new discrepancies by separating the library and configuration results files.

My ideas were:

• for laziness, to easily check what was finally configured (e.g. my FFmpeg xp)
• to have these two information, to be sure that you don't have mess up something with for instance system library (could be ROS OpenCV, Python, ...) / your lib path, your OpenCV build, ...

Anyway, feel free to close this ticket if not relevant.

from opencv.

I think it is better to request for comment. I'm sure there are others who have other opinions.

I said that separating libraries and configuration files has a trade-off between the advantage of easily checking build configurations with configuration files and the disadvantage of trusting the wrong information in configuratioin files if we are unlucky enough to mix up the configuration files.

And I think this is a matter of which is greater, the advantage or the disadvantage.

(Just idea) by adding the hash information of the generated libraries as supplementary information after the build is complete, we can verify the consistency between the configuration file and the libraries. However, I don't think that level of verification is necessary.

from opencv.

If we don't care about unnecessary decorations derived from C language strings( "" and "\n"s ), just adding these few lines will allow it to be installed with any name.
(so this example uses ".inc" extension, not ".txt")

I confirmed the effect on Ubuntu 24.04. I have not confirmed it on platforms such as Windows or macOS. I believe that cmake will probably do a good job.

diff --git a/cmake/OpenCVUtils.cmake b/cmake/OpenCVUtils.cmake
index 444aa7cedd..f5c8528ed7 100644
--- a/cmake/OpenCVUtils.cmake
+++ b/cmake/OpenCVUtils.cmake
@@ -970,6 +970,10 @@ macro(ocv_finalize_status)
   unset(__content)
   unset(OPENCV_BUILD_INFO_STR CACHE)

+  install(FILES ${OPENCV_BUILD_INFO_FILE}
+            DESTINATION "${OPENCV_OTHER_INSTALL_PATH}"
+            RENAME "opencv_build_information.inc")
+
   if(NOT OPENCV_SKIP_STATUS_FINALIZATION)
     if(DEFINED OPENCV_MODULE_opencv_core_BINARY_DIR)
       execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different "${OPENCV_BUILD_INFO_FILE}" "${OPENCV_MODULE_opencv_core_BINARY_DIR}/version_string.inc" OUTPUT_QUIET)

result (opencv_build_information.inc is installed).

$ sudo ninja install | grep -B 5 -A 5 opencv_bui
-- Up-to-date: /usr/local/lib/cmake/opencv4/OpenCVModules.cmake
-- Up-to-date: /usr/local/lib/cmake/opencv4/OpenCVModules-release.cmake
-- Up-to-date: /usr/local/lib/cmake/opencv4/OpenCVConfig-version.cmake
-- Up-to-date: /usr/local/lib/cmake/opencv4/OpenCVConfig.cmake
-- Up-to-date: /usr/local/bin/setup_vars_opencv4.sh
-- Installing: /usr/local/share/opencv4/opencv_build_information.inc
-- Up-to-date: /usr/local/share/opencv4/valgrind.supp
-- Up-to-date: /usr/local/share/opencv4/valgrind_3rdparty.supp
-- Up-to-date: /usr/local/share/licenses/opencv4/libopenjp2-README.md
-- Up-to-date: /usr/local/share/licenses/opencv4/libopenjp2-LICENSE
-- Up-to-date: /usr/local/share/licenses/opencv4/openexr-LICENSE

from opencv.