#232 CMake build
I am thinking about adding support for CMake build tool to the FreeImage. I would like to ask you about your opinion? I've created patch for current CVS version.
I have good experience with this build tool and we are using it for several years. My objectives why to add support for CMake:
- Does not break current build process, only CMakeLists.txt is added to the each directory
- Can generate project files for the Visual Studio (no need to maintain several .sln/.vcproj files)
- Build process can be configured, e.g.:
- LibJPEG, Zlib, LibTiff - could be used as external libraries or internal versions (as it is now).
If application is using other imaging library (e.g. Leptonica) it would be good to use only single LibJPEG library.
- It works on *nix systems
- It allows to simply build FreeImage in three modes:
* static build
* single FreeImage.dll
* multiple DLLs: FreeImage, FreeImageJpeg.dll, FreeImagePng.dll, FreeImageTiff.dll, FreeImageZlib.dll
What do you think about this idea and my patch?
Using CMake seems The Right Thing to do, but who and to what extend will support it in the future? Does the makefiles produced compile on all platforms, FI has often problems compiling on OSX, I personally managed to compile only the static build (using clang)?
A cross-platform build system is a dream come true, but only if it is working and exceptionally well supported (updated for every new os version, reasonably backwards compatible, etc). The latter is crucial, because CMake adds another level of indirection and hacking something that does not work out of the box is many time harder then "just" fixing the makefiles.
Also, as a personal request, it will be very helpful to have debug builds alongside release ones! Without that feature a new build system is close to useless for me, especially if it is hard(er) to hack a solution.
BTW you should probably move this discussion to the forums.
I found this CMakeLists.txt file to compile FreeImage:
https://github.com/QbProg/oce-win-bundle/blob/master/FreeImage.cmake/CMakeLists.txt
By the way CMake should be the minimum every opensource cross-platform project should support :D, there are still lot of projects using it in a wrong way but CMake ALWAYS permitt to create easy to maintain and simple build files:
1) It has build identity concept so you can have alongside both Debug and Release build (It is common to see used following 4 targets: Debug, Release, MinSizeRel, RelWithDebInfo.... But I fear people should use Debug, Release, Profile, Test wich are much more convenient.. it is useless having 2 different optimizations, there should be only 1 handcrafted optimization for release mode while the other 3 targets should be standard stuff handed by CMake or some common Cmake script)
2) Most common flags are handled by Cmake (no warry about static or shared library, linker flags you could also gather source files with directories and REGEX expressions) and you get IDE projects files almost for free.
3) There are already script files for Android (without Cmake every android c/c++ project is potentially painfull)
4) there's no need to hack, never had problems with cmake, I only had problems with people using cmake in wrong way (I don't know who wrote the script I linked above, but it is done pretty well, it uses all good CMake patterns, it is possible there are just 1 o 2 missing details that only who know the platform compiling for or who wrote FreeImage may know.)
I can give some help designing/maintainng CMakeLists.txt for FreeImage (if you need so).
I posted about external libraries yesterday to the discussion forum [ee1d5abf]. While the patch I'm currently using is just a modification of the current makefile system, a cmake method might be a little more portable. Cmake does have a slightly steeper starting curve, but should be OK once up and running. Debian, Gentoo, and Fink (maybe other distros, as well) patch to use external libraries, so it would be nice to set up a way to allow packagers to do it with just some compile time flags vs needing large homegrown patches.
Related
Discussion: ee1d5abf
I'm very much against multiple DLLs (FreeImageJpeg.dll and so on), because I dislike segregation and ultimately that's what the plugin system is for. I very much welcome external libraries (libjpeg and so on), because this opens up its use in Linux.