[fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based
mateusz at loskot.net
Fri May 23 20:28:49 EDT 2008
I've reviewed the RFC 21 and here are my comments and questions:
1. Q: Why CMake is only considered as a replacement for autotools, but
not only for hand-crafted Visual Studio solutions?
2. I think it's a good idea to keep the Thirdparty directory for users
convenience, at least for next 1-2 releases, until we observe that
versions of FDO deps shipped in various Linux distributions work
smoothly with FDO.
3. Comment to Greg's: "The purpose of including the Thirdparty (...)"
I believe we can define in the FDO documentation what are minimal
required versions of dependency packages. This is a well-know and
pretty standard way in the Linux world, and usually works.
4. I'd also suggest to separate these two tasks:
1) Introduction of CMake as main build system
2) Provide support to build against external sources of FDO
dependencies and (optionally) removal of the Thirdparty module.
5. CMake is a replacement for the chain of automake + autoconf +
libtool + m4 + other friends. So, there is no need to worry about waht
versions of these are available in user's environment
6. CMake will shorten building time cost significantly. Libtool is
known from that it very slows building process. I think Quantum GIS
team can share their experiences in this matter.
7. Comment to "100% safe transition":
I agree, CMake configuration will not affect current based on
autotools. Both can live together without any problems.
8. Regarding the CMake adoption: I'd suggest to focus on as simple
case as possible in the first phase of incorporating and testing CMake
setup, for instance FDO + SHP provider only.
9. KDE migrated to CMake in somewhat automated way, using am2cmake 
made by KDE for that purpose. Perhaps, it could be useful for us too.
10. I recommend CMake Cool Features as an abstrac of what CMake may
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
More information about the fdo-internals