[fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

[Helio Chissini de Castro]

Em Friday 23 May 2008 21:28:49 Mateusz Loskot escreveu:
> 1. Q: Why CMake is only considered as a replacement for autotools, but
> not only for hand-crafted Visual Studio solutions?
I just submitted rfc this way because i'm doing linux work. Never excluded 
Windows, just pick the obvious first choice for now.

> 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.
I will modify the cmake build to adopt Thirdparty tools as an optional build 
too

> 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.

Yes, that's it.

> 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

Yrp

> 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.

And talking about linux side, with the approach of Gnu Gold linker, this will 
speedup in 60% the build time. Already tested.

> 7. Comment to "100% safe transition":
> I agree, CMake configuration will not affect current based on
> autotools. Both can live together without any problems.

And that's why the patch is done now. 

> 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.

Provided Postgis and SHP on patches

> 9. KDE migrated to CMake in somewhat automated way, using am2cmake [1]
> made by KDE for that purpose. Perhaps, it could be useful for us too.

am2cmake was ok to initial port, but was too kde oriented and had some 
failures in more broadwide auto*tools script. I forked that script to embrace 
fdo and mapguide on initial cmake build.

-- 
Helio Chissini de Castro
KDE Project
Brasil and South America Primary Contact