Closed Innokentiy-Alaytsev closed 6 years ago
Thanks for the changes, it might take me a a while to review and test everything. I think some of the build issues (like the C++11 checks, automoc etc) were caused by cmake bugs when I started this project years ago, hopefully everything works in modern versions.
Changes look alright and builds fine for me, merging thanks
The intention of the changes is to improve the project build process. The new CMake build script provides the following:
Proper versioning. First of all, the version is bumped to 2.0.0. At some point, all classes in the library were moved in a separate namespace. This change has broken the backward compatibility because both ABI and source level interface has changed. Unfortunately, the major version was not bumped back then, so I had some problems with updating this library.
1.1. Under Windows, some information about library version and copyright will be included in the resulting DLL file.
1.2. The library now provides a set of functions that provide different information about the library version. The users of the library may use this functions to get library version to include in "About" dialogue. These functions are also useful for any developer who wants to know what is the exact version of the library file.
1.3. The major version is included in resulting library file (DLL, lib, so). This may not be the right behaviour. I do not know what does "1" means in the old file name (ColorWidgets-qt51), but I guess this is a major version to indicate the API that the library provides.
1.4. The output library file is called QtColorWidgets-Qt52 now, where "5" is Qt version and "2" is library major version. Changing the name of the output file makes it obvious to the users that the library is different now.
The CMake project now has better INSTALL target. Calling this target results in the creation of basic directory hierarchy under CMAKE_INSTALL_PREFIX, where the bin directory contains .dll file, include directory contains library headers is subdirectory "QtColorWidgets", lib contains .so/.a/.lib files (I am not sure about the exact location of .a and .so files because I don't test under Linux). The lib directory also contains the cmake directory with .cmake files that are used by find_package () function and pkg-config directory with a .pc file for the pkg-config tool. The last two directories are the main improvement - now it is fairly easy to use QtColorWidgets in CMake project.
The header files are moved in QtColorWidgets subdirectory, the sources are moved in src/QtColorWidgets directory. Such separation simplifies installation of the library.
The headers are installed and expected to be under QtColorWidgets directory. I think, this simplifies usage of the library because the headers are easier to find and identify.
Compile time definitions are fixed so that the library now properly compiles under MSVC. Original version of build script did not define QTCOLORWIDGETS_LIBRARY during the build so the symbols were not exported. Everything was OK under GCC where all symbols are exported by default, but under MSVC CMake build was broken due to symbols being hidden by default.
Qt Designer plugin project is changed to make it work with the new library build script. The plugin successfully builds and works under Windows. I guess everything should be OK on other platforms.
6.1. Custom installation commands were removed because they are not portable between operating systems. For example, if I install Qt under Program Files on Windows (I do not think that doing so is a good idea, as well as using Windows, but things happen), then the CMake INSTALL target will fail because this directory is read-only. I think that there are some other examples where it is not desired for the plugin to be installed.
gallery project is changed to make it work with the new library build script.
AUTOMOC, AUTOUIC and AUTORCC are enabled now. I do not know why they were disabled in the past. AFAIK, these tools work perfectly well.
Compiler version check is changed. I have seen the comments about built-in functions not problems, but the used way of checking C++11 support did not properly work under MSVC.
Overall, at some places the CMake script has become a bit overcomplicated, This is because I try to make the script as universal as possible to make it possible to make little change between different projects.