Suggestion for a more explicit version_string.tmp filename

[s-trinh]

Describe the feature and motivation

To get OpenCV build information at execution: one can use getBuildInformation()

I would suggest to rename or copy the version_string.tmp file (

opencv/cmake/OpenCVUtils.cmake

Lines 958 to 984 in 12e2cc9

	macro(ocv_finalize_status)
	set(OPENCV_BUILD_INFO_FILE "${CMAKE_BINARY_DIR}/version_string.tmp")
	if(EXISTS "${OPENCV_BUILD_INFO_FILE}")
	file(READ "${OPENCV_BUILD_INFO_FILE}" __content)
	else()
	set(__content "")
	endif()
	if("${__content}" STREQUAL "${OPENCV_BUILD_INFO_STR}")
	#message(STATUS "${OPENCV_BUILD_INFO_FILE} contains the same content")
	else()
	file(WRITE "${OPENCV_BUILD_INFO_FILE}" "${OPENCV_BUILD_INFO_STR}")
	endif()
	unset(__content)
	unset(OPENCV_BUILD_INFO_STR CACHE)
	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)
	endif()
	endif()
	if(UNIX)
	install(FILES "${OpenCV_SOURCE_DIR}/platforms/scripts/valgrind.supp"
	"${OpenCV_SOURCE_DIR}/platforms/scripts/valgrind_3rdparty.supp"
	DESTINATION "${OPENCV_OTHER_INSTALL_PATH}" COMPONENT "dev")
	endif()
	endmacro()

) to something more explicit (e.g. opencv_build_information.txt). This way, the user could easily identify the generated CMake configuration.

Suggestion to use also https link here: https://github.com/opencv/opencv/blob/12e2cc9502bc51bb01ed3fdd2f39ce1533c8236e/cmake/OpenCVVersion.cmake#L27C47-L27C57

Additional context

I was for instance dealing with some FFmpeg dependency issues and version incompatibility with ppa:jonathonf/ffmpeg4 being discontinued. When running ccmake, FFMpeg was set to YES but then OpenCV was built without FFmpeg support due to some incompatibility between the dev packages.

[Kumataro]

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

[s-trinh]

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.

[Kumataro]

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.

[Kumataro]

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