Solved issue #118 "Missing VERSION_INFO when compiling as Windows DLL" #120
Conversation
…atic libraries are built
…compiling as Windows DLL" using CMakeHelpsers from https://github.com/halex2005/CMakeHelpers. CMakeHelpers must be place in the same directory as / parallel to utf8proc. For English resource language you need to replace the following things in the CMakeHelpers/VersionResource.rc file: FILEFLAGSMASK 0x3fL with FILEFLAGSMASK 0x17 LANGUAGE LANG_RUSSIAN, SUBLANG_DEFAULT with LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT BLOCK "041904b0 with BLOCK "040704b0" VALUE "Translation", 0x419, 1200 with VALUE "Translation", 0x407, 1200
|
I don't like the idea of the build script depending on CMakeHelpers being installed in a particular directory outside the source tree. CMakeHelpers is MIT-licensed, and https://github.com/halex2005/CMakeHelpers/blob/master/generate_product_version.cmake hasn't changed in 3 years. Maybe we should just include it in utf8proc? |
|
First I had the same idea to include CMakeHelpers in utf8proc but then I choose the parallel solution because this way I can use it for other projects too where the version info is needed and to be completely independent (no "copy/paste" code that needs to be merged when changes occur - especially important if more than one project uses CMakeHelpers). The CMakeLists.txt file checks if CMakeHelpers is installed and uses it to generate and add the version info or no version info is generated / added - as before. |
|
Bundling a version that is known to work for utf8proc will be much less fragile. |
…32/utf8proc.rc file (subject to change) in case of BUILD_SHARED_LIBS AND MSVC.
… specify compile definitions for target "utf8proc" which is not built by this project.
|
Because you don't like the idea of the build script depending on CMakeHelpers, but I need a version number for the DLL version of utf8proc for Windows I propose the following solution based on a win32/utf8proc.rc file that is only added in case of BUILD_SHARED_LIBS AND MSVC (see CMakeLists.txt) - this is nearly the same solution that zlib uses except zlib needs an entry (#define) in the header file (that is used in the .rc file) that I pass as definition UTF8PROC_VERSION to Visual Studio so the impact and duplicate code is lesser. |
|
I updated the VERSION_INFO to 2.4.0 |
CMakeLists.txt
Outdated
| set(SO_MINOR 3) | ||
| set(SO_PATCH 1) | ||
| set(SO_MINOR 4) | ||
| set(SO_PATCH 0) |
There was a problem hiding this comment.
As the comment in the Makefile says, these numbers indicate ABI compatibility and don't follow the API version number exactly. From 2.3 to 2.4 there was no change in ABI which is why the minor version stayed 3.
There was a problem hiding this comment.
Though it's probably easier for us to just match the API number in the future so that we don't have this discussion repeatedly.
In any case, please don't update these now.
|
I refactored the version info problem on Windows and removed the definitions from CMakeLists.txt and moved it to utf8proc.h where the UTF8PROC_VERSION_MAJOR, UTF8PROC_VERSION_MINOR and UTF8PROC_VERSION_PATCH is defined. |
|
Do you have any objects to this new solution? |
This solves JuliaLang/utf8proc issue #118 "Missing VERSION_INFO when compiling as Windows DLL" using CMakeHelpsers from https://github.com/halex2005/CMakeHelpers. CMakeHelpers must be placed in the same directory as / parallel to utf8proc.
For English resource language you need to replace the following things in the CMakeHelpers/VersionResource.rc file:
FILEFLAGSMASK 0x3fL with FILEFLAGSMASK 0x17
LANGUAGE LANG_RUSSIAN, SUBLANG_DEFAULT with LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT
BLOCK "041904b0 with BLOCK "040704b0"
VALUE "Translation", 0x419, 1200 with VALUE "Translation", 0x407, 1200