| Version 1 (modified by , 16 years ago) ( diff ) |
|---|
FDO RFC 21 - New Linux Buildsystem Cmake Based
This page contains a request for comments document (RFC) for the FDO Open Source project. More FDO RFCs can be found on the RFCs page.
Status
| RFC Template Version | (1.0) |
| Submission Date | May 20, 2008 |
| Last Modified | Helio Castro Timestamp |
| Author | Helio Castro |
| RFC Status | Draft |
| Implementation Status | Under Development |
| Proposed Milestone | 3.3.x |
| Assigned PSC guide(s) | |
| Voting History | (vote date) |
Overview
On the current status of FDO over Linux and *nix platforms there's a huge need to rely on third party included sources, as well all providers can't be independently built, depending of whole infrastructure of core FDO sources to be available. This proposal is to move whole builds for a modern text based, human readble buildsystem, suitable to even become windows buildsystem in future.
Motivation
FDO is suppose to become *the* standard for map manipulation on opensource, but current automake,autoconf linux and *nix buildsystem together with the difficulty of rely in private headers and very old versions of some libraries, like cppunit, make almost impossible to provide it as a consistent package for distribution. The situation is workst when we deal that in many cases static and shared libraries are been linked together, and compilers like gcc sometimes not play so nice with this ( really ).
This creates a complication over the present distributions situations, as some libraries present conflicts with the thirdparty ones provided, and make FDO opensource not widespread available on major distributions.
The whole motivation behind the change is make FDO not touch any kind of internal thirdparty sources, using only provided distribution libraries, and make it easy to compile and work with core or providers separated. CMake is one of the frameworks that allow us to do this.
With this, the possibilities of improvement are huge, as will become easy to deal with debugging/analysing independent parts of code, without rely on restart whole bs scripting.
Proposed Solution
Most of this proposals presented here are in the READY TO DEPLOY state, unless some exceptions stated below
Get rid of whole auto*tools
- None of the current .am .in tools will be necessary anymore.
Get rid of ThirdParty tools
- With the new buildsystem, it will be suppose to use external shared only system libraries. The only present issue is about sqllite internal header dependency to solve.
- Common tools like mkcatdefs are splitted in an independent source standalone with their own cmake build.
Been able to compile any provider without need to be inside FDO main code"
- Providers compile itself, just requiring that fdo core lib and headers is installed and cmake knows where to look.
- Providers not need anymore been developed inside the fdo tree.
Rearrange fdo headers install
- To enable providers become an entity, some headers ignored before are now needed to be installed in their own include dir. New buildsystem do this automatically
Create proper library naming/module
- Today fdo provides .so only files, mixing devel and not devel symbols. FDO core is moved to have prober soname and devel .so. Same to Providers, but further study can make providers to become module only, not needing rely anymore to become .so.*
Been able to install in any directory withou harm applications using it
- New buildsystem do automatically the necessary changes in files to provide access doesn't matter the dir user decides to install. The original place was /usr/local/fdo-<version>
Rewrite SQLiteInterface utility
- Current sqlite interface utility is dealing with internal sqlite headers. Sdf provider needs that. Mapguide not compiles without Sdf providers ( suggests to create a test to compile or not on mapguide ). To make it feasible, a rewrite is needed to use only standard sqlite headers.
Test Plan
- Patches are ready to be provided against fdo-3.3.1 code and tested.
- The new buildsystem can be introduced an commited in current trunk tree without affect any of current development and touching old files for now. 100% safe transition.
Issues
- Not all providers are converted. Is just manual work. Currently sdf, shp, postgist and gdal are done.
- Still need to rely in private sources ( sqlite )
- Not tested in many linux distros ( did on Mandriva, Suse and RH/Fedora )
- Not tested in *nix ( did on OpenSolaris build only )
