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

Wed May 21 16:11:29 EDT 2008

Other questions....

1)      How would a user build all of FDO, Utilities and Providers in the SVN?

2)      How would a user build a user-specified subset of FDO, Utilities and Providers?

Thanks,

Greg

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Wednesday, May 21, 2008 4:06 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

[GB] See inline...

[GB] also...

 1.  What source code changes are being proposed, if any?
 2.  What installed content are being proposed as a result of the new build system?
a.        Can we get a comparison of the before/after result of building a full version of FDO and all it's providers?
b.       What changes are applications expected to make in order to use the installed output?

 1.  Can you give a brief outline of the source/build files that will be added/removed/modified in the SVN?
 2.  Will the build_linux.sh files be maintained?
 3.  Who will document the new build system for our users?
 4.  On which Linux systems will the new build system be officially tested?
 5.  How are Windows .vcproj and .sln files generated from the cmake files?
c.        How can custom .vcproj actions currently defined in the .vcproj files be captured by the cmake files?

Please incorporate all responses in the RFC itself.

-----------
FDO RFC 21 - New Linux Buildsystem Cmake Based ¶<http://trac.osgeo.org/fdo/wiki/FDORfc21>
This page contains a request for comments document (RFC) for the FDO Open Source project. More FDO RFCs can be found on the RFCs<http://trac.osgeo.org/fdo/wiki/FDORfcs> page.
Status ¶<http://trac.osgeo.org/fdo/wiki/FDORfc21>
RFC Template Version

(1.0)

Submission Date

May 20, 2008

Last Modified

Helio Castro Wed May 21 15:22:59 2008

Author

Helio Castro

RFC Status

Draft

Implementation Status

Under Development

Proposed Milestone

3.3.x

Assigned PSC guide(s)

Voting History

(vote date)

Overview ¶<http://trac.osgeo.org/fdo/wiki/FDORfc21>
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 readable build system, suitable to even become windows build system in future.
Motivation ¶<http://trac.osgeo.org/fdo/wiki/FDORfc21>
FDO is suppose to become *the* standard for map manipulation on open source, but current automake, autoconf Linux and *nix build system 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 worse 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 open source 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.
[GB] The purpose of including the Thirdparty directory is to simplify the user's development experience so that he/she do not have to determine which versions/builds of the relevant Thirdparty software are supported. By including a version of a Thirdparty component in our SVN, we guarantee that our software works with that version. How do you propose to handle the cases where a user a) does not want to have to figure out which version (or if his version) is supported or b) that the version he uses runs but is not 100% compatible, resulting in runtime errors, loss of functionality, etc?
With this, the possibilities of improvement are huge, as will become easy to deal with debugging/analyzing independent parts of code, without rely on restart whole bs scripting.
[GB] Can you elaborate on the meaning of this statement in greater detail and further document the expected improvements that will result? What does "bs scripting" refer to?
Proposed Solution ¶<http://trac.osgeo.org/fdo/wiki/FDORfc21>
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<http://trac.osgeo.org/fdo/wiki/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.
[GB] Can you describe this section in greater detail? How has this improvement been tested? What happens if no FDO is installed and the FDO binaries currently reside in their current build system locations?
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.
[GB] Can you describe this in greater detail? We have external applications which rely on the current install directory pattern.
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.*
[GB] Can you describe this in greater detail? We have applications in production which rely on the current library names.
Been able to install in any directory without 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>
[GB] Installation into a user specified directory is already supported as long as the $FDOHOME environment variable is set. Even if the cmake system is adopted, setting $FDOHOME will still be required. What level of testing has been done to validate enhanced install location support?
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.
[GB] If MapGuide needs SDF, then how can a solution be implemented that involves not compiling SDF? Also, if a rewrite is required, that must be explicitly spelled out in this document.
Test Plan ¶<http://trac.osgeo.org/fdo/wiki/FDORfc21>
- Patches are ready to be provided against fdo-3.3.1 code and tested. - The new buildsystem can be introduced an committed in current trunk tree without affect any of current development and touching old files for now. 100% safe transition.
[GB] Can you elaborate on what "tested" means?
Issues ¶<http://trac.osgeo.org/fdo/wiki/FDORfc21>
* 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?<http://trac.osgeo.org/fdo/wiki/OpenSolaris> build only )
[GB] Are you proposing that all providers be converted before adopting such a system or only a subset?
Funding/Resources ¶<http://trac.osgeo.org/fdo/wiki/FDORfc21>

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Helio Chissini de Castro
Sent: Tuesday, May 20, 2008 10:35 AM
To: FDO Internals Mail List
Subject: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

Hello people

I just started my first RFC about the buildsystem changes. Now of course
starting on FDO.

http://trac.osgeo.org/fdo/wiki/FDORfc21

Regards

--
Helio Chissini de Castro
KDE Project
Brasil and South America Primary Contact
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080521/c3071705/attachment-0001.html