FDO RFC 21 - New Linux Buildsystem Cmake Based

[Helio Chissini de Castro]

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Jason Birch]

Thanks for taking the time/effort to put together this RFC and doing the
work to implement this packaging in the past.  Can we assume that you
are willing to help undertake the reorganisation required to move to the
use of cmake for FDO's linux and Windows builds?

In general, this looks pretty good to me.  I would like to see more
information on specific benefits of moving to this kind of build system
from different perspectives.

For instance, for user-installers of FDO, does this allow for an easier
build process across multiple Linux distributions, or even automated
creation of installer packages (apt, yum, whatever)?  For build
managers, does it allow for the maintenance of Linux, VS2005, and VS2008
solutions in a central interface?

What would be the effect on individual developers; would they have to
install additional dependencies (for cmake)?  Is cmake available across
multiple platforms?

What kind of impact will this have on existing build procedures and
end-user documentation for building FDO?

I'm personally interested in cpack... do you have any experience with
using this to create packages/installers for Linux and Windows?

I am not convinced that going to generic libraries will be possible in
all cases, especially where libraries have been patched for specific
functionality or performance that has not been integrated into the
upstream project.  Does cmake not allow for internal copies of
libraries, or is this just a general clean-up item?  I would, however,
personally advocate that FDO use generic libraries whenever possible,
and that maintaining a locally-patched version of libraries not be
supported as a standard practice.  This would allow FDO to integrate
better into the OS community in general, and would allow for far easier
integration into common installers such as OSGeo4W and FGS.

Jason

-----Original Message-----
From: Helio Chissini de Castro
Subject: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

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

starting on FDO.
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Helio Chissini de Castro]

Em Tuesday 20 May 2008 14:49:32 Jason Birch escreveu:
> Thanks for taking the time/effort to put together this RFC and doing the
> work to implement this packaging in the past.  Can we assume that you
> are willing to help undertake the reorganisation required to move to the
> use of cmake for FDO's linux and Windows builds?

For start linux, since will not affect windows build. Then after we have the
stable linux build, we can add windows part.

> For instance, for user-installers of FDO, does this allow for an easier
> build process across multiple Linux distributions, or even automated
> creation of installer packages (apt, yum, whatever)?  For build
> managers, does it allow for the maintenance of Linux, VS2005, and VS2008
> solutions in a central interface?

I already have the package for Mandriva, and yes, would be easy to do
packages, at least packagers for distros will have easy access to that.
Cmake provides automatic VS 2005 and 2008 project generation from the same
CMakeFiles and for XCode in mac environments,  which means one file will
provide same infra for all platforms.

> What would be the effect on individual developers; would they have to
> install additional dependencies (for cmake)?  Is cmake available across
> multiple platforms?
cmake is available in all platforms and usually mostly distros already have
recent packages for it.
Developers will need install the dependencies that was in the past inside
ThirdParty dir

> What kind of impact will this have on existing build procedures and
> end-user documentation for building FDO?

Today, what user will need to do is:
cd OpenSource_FDO
mkdir build && pushd build
cmake ..
make
make install

That's it.I did common cmake tests for every dependency really requires and
warn developer about  

especial flags can be passed in the cmake stage, like
cmake .. -DDEBUG -DCMAKE_INSTALL_PREFIX=/usr/lib/fdo

> I'm personally interested in cpack... do you have any experience with
> using this to create packages/installers for Linux and Windows?

I barely had time to analyse cpack, as i'm usual to do RPM packages for
Mandriva. I can take a look on that.

> I am not convinced that going to generic libraries will be possible in
> all cases, especially where libraries have been patched for specific
> functionality or performance that has not been integrated into the
> upstream project.  Does cmake not allow for internal copies of
> libraries, or is this just a general clean-up item?

For mapguide as an example, we have GD that have special needs, so i decided
keep the copy inside and build it naming gdmapguide, so basically is just
another library linked that not conflicts with system one.
Of course if this specific cases appears, there's no way to deal except have
an internal copy. The only thing i took care is keep everything possible as a
shared library.

[]'s

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

[Greg Boone]

Some javascript/style in this post has been disabled (why?)

[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?

1. Can we get a comparison of the before/after result of building a full version of FDO and all it’s providers?
2. What changes are applications expected to make in order to use the installed output?

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

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

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

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 ¶

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 ¶

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.

[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 ¶

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

* 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 )

[GB] Are you proposing that all providers be converted before adopting such a system or only a subset?

Funding/Resources ¶

 

 

-----Original Message-----
From: [hidden email] [[hidden email]] 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

[hidden email]

http://lists.osgeo.org/mailman/listinfo/fdo-internals

 

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Greg Boone]

Some javascript/style in this post has been disabled (why?)

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: [hidden email] [mailto:[hidden email]] 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?

3. Can you give a brief outline of the source/build files that will be added/removed/modified in the SVN?
4. Will the build_linux.sh files be maintained?
5. Who will document the new build system for our users?
6. On which Linux systems will the new build system be officially tested?
7. 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 ¶

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

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 ¶

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 ¶

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.

[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 ¶

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

* 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 )

[GB] Are you proposing that all providers be converted before adopting such a system or only a subset?

Funding/Resources ¶

 

 

-----Original Message-----
From: [hidden email] [[hidden email]] 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

[hidden email]

http://lists.osgeo.org/mailman/listinfo/fdo-internals

 

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Helio Chissini de Castro]

On Wednesday 21 May 2008, Greg Boone wrote:
> How would a user build a user-specified subset of FDO, Utilities and
> Providers?

All question answered in RFC, including the ones from Jason

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Greg Boone]

Can you create an SVN patch of all your changes so far and mail it to me? I think it would help me understand the scope of the proposed changes if I see the actual code and build script changes I may be able to determine any potential impact.

Also, are you targeting this for the 3.3 branch? I would be opposed to submitting your proposed changes to that branch. I am of the opinion that any changes you have proposed should only be made in the FDO SVN trunk, which is FDO 3.4.0. When you send me the SVN patch file, please have it reference the files contained in the trunk.

Regards,
Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Wednesday, May 21, 2008 9:19 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

On Wednesday 21 May 2008, Greg Boone wrote:
> How would a user build a user-specified subset of FDO, Utilities and
> Providers?

All question answered in RFC, including the ones from Jason

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Jason Birch]

Or if it's not too big, attach it to the RFC so that we can all see it
:)

If it's too big, I can put it up on my personal site and link to it from
the RFC.

Jason

-----Original Message-----
From: Greg Boone
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake
Based

Can you create an SVN patch of all your changes so far and mail it to
me? I think it would help me understand the scope of the proposed
changes if I see the actual code and build script changes I may be able
to determine any potential impact.
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Mateusz Loskot]

On May 22, 2008, at 8:12 PM, Greg Boone wrote:
> Can you create an SVN patch of all your changes so far and mail it  
> to me? I think it would help me understand the scope of the proposed  
> changes if I see the actual code and build script changes I may be  
> able to determine any potential impact.

What about submitting this patch as a ticket?
This way it's easy to observe changes as outlined by Trac diff  
mechanism.

> Also, are you targeting this for the 3.3 branch? I would be opposed  
> to submitting your proposed changes to that branch. I am of the  
> opinion that any changes you have proposed should only be made in  
> the FDO SVN trunk, which is FDO 3.4.0. When you send me the SVN  
> patch file, please have it reference the files contained in the trunk.

I support Greg's opinion.

I'm going to re-read more carefully the RFC 21 tonight and send my  
comments.
So, I'd also appreciate if I have access to the entire patch, preferable
submitted as a ticket.

--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org




_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Greg Boone]

Agreed, attaching the SVN Ticket is a better option.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Thursday, May 22, 2008 2:28 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

Or if it's not too big, attach it to the RFC so that we can all see it
:)

If it's too big, I can put it up on my personal site and link to it from
the RFC.

Jason

-----Original Message-----
From: Greg Boone
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake
Based

Can you create an SVN patch of all your changes so far and mail it to
me? I think it would help me understand the scope of the proposed
changes if I see the actual code and build script changes I may be able
to determine any potential impact.
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Mateusz Loskot]

Folks,

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 [1]  
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  
give us.

[1] http://wiki.kde.org/tiki-index.php?page=KDE+CMake+Intro#_How_do_I_convert_my_own_autotools_based_KDE_software_to_cmake_

[2] http://www.cmake.org/Wiki/Really_Cool_CMake_Features
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org




_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Helio Chissini de Castro]

Em Thursday 22 May 2008 15:33:05 Greg Boone escreveu:
> Agreed, attaching the SVN Ticket is a better option.
>

Hi people, just back from the extended holidays in Brazil.
I posted the current patches here: http://www.geolinux.com.br

There's is the fdo cmake patches, the four ones to do small code changes (
xalan, etc.. )

For proof of concept purpose, there are the patches for postgis and shp
providers too.

Notes:
- The patches are made on the purpose to have all external libraries, except
for Thirdparty sqlite ( reasons specified in rfc )
- Patches are made against 3.3.1 release. I did't had time to do against svn
trunk, but i think applied as well

For build:
- Install cmake >= 2.4.6
- create some directory for the object files ( i usually create a dir called
build )
- enter the directory and do cmake <fdo_source_dir>
- make e make install
- If you want install ina different place to see resultant tree, do
make DESTDIR=<somedir> install

Notes for testers with new gcc 4.3.1
Gcc 4.3.1 becomes pedantic in many ways, which lead fdo to not compile at all
untill put right headers. Ex. strlen is provided for string.h and only there.
Before, including stdio.h would be enough, since stdio get the string.h. Now
don't, so there's many places that will need to be verified to add proper
include headers. Is just a pedantic annoyance, but will be needed in near
future.

[]'s

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

[Helio Chissini de Castro]

Em Sunday 25 May 2008 14:36:14 Helio Chissini de Castro escreveu:

> Em Thursday 22 May 2008 15:33:05 Greg Boone escreveu:
> > Agreed, attaching the SVN Ticket is a better option.
>
> Hi people, just back from the extended holidays in Brazil.
> I posted the current patches here: http://www.geolinux.com.br
>
> There's is the fdo cmake patches, the four ones to do small code changes (
> xalan, etc.. )
>
> For proof of concept purpose, there are the patches for postgis and shp
> providers too.
>
> Notes:
> - The patches are made on the purpose to have all external libraries,
> except for Thirdparty sqlite ( reasons specified in rfc )
> - Patches are made against 3.3.1 release. I did't had time to do against
> svn trunk, but i think applied as well
>
> For build:
> - Install cmake >= 2.4.6
> - create some directory for the object files ( i usually create a dir
> called build )
> - enter the directory and do cmake <fdo_source_dir>
> - make e make install
> - If you want install ina different place to see resultant tree, do
> make DESTDIR=<somedir> install
>
> Notes for testers with new gcc 4.3.1
> Gcc 4.3.1 becomes pedantic in many ways, which lead fdo to not compile at
> all untill put right headers. Ex. strlen is provided for string.h and only
> there. Before, including stdio.h would be enough, since stdio get the
> string.h. Now don't, so there's many places that will need to be verified
> to add proper include headers. Is just a pedantic annoyance, but will be
> needed in near future.
>
> []'s

I forgot one thing.
I separated mkcatdefs in a separated package on Mandriva, I will provide a
future patch using the Thirdparty mkcatdefs

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

[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
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Jason Birch]

Hi Helio (is that an OK form of address?),

Any update on making the initial patch available?  I'd really like to
see how this stuff works :)

Jason
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Helio Chissini de Castro]

On Tuesday 17 June 2008 13:01:17 Jason Birch wrote:
> Hi Helio (is that an OK form of address?),
>
> Any update on making the initial patch available?  I'd really like to
> see how this stuff works :)
>
> Jason

Ok, back from the darkness ( also know as managing a whole part from a future
linux distro release to be out in first alpha )

I sent two weeks the signed form about commits right ( by fax ) and finishing
the second buildsystem cleanup, based on trunk now.
windows build is been slowly introduced now, but for this i will need help
from widows guys too.
Instead of push the minor changes in code to avoid some unexpected surprises,
if gcc is detected the FORTIFY_SOURCE flags are added to gcc behaves as in old
< 4.3 releases.

I will upload the new version  as soon as i back from OSCON next week.

For who not seen the first version of buildsystem patches, they are here for
3.3.1: http://www.geolinux.com.br/

[]'s

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

[Greg Boone]

Hi Helio,

You should really get the RFC approved by the PSC before moving too far ahead with the implementation. As a part of the RFC approval, you will have to provide responses on how you have addressed the concerns I originally voiced some time ago:

If the changes are submitted:

1) Can a full build, that includes FDO and all providers, be run in batch, without the need for any FDO/Thirdparty components to be installed?
2) Will new build routines for all FDO, providers and Utility projects be supported as a part of the RFC code submission?
3) Will the build documentation be updated as a part of the submission?
4) How will build validation be performed?

I also recommend not deleting any existing build files as a part of your eventual submission so that both build options can co-exist until all the kinks are worked-out.

You also need to outline how the Windows build will be affected. Just to give you a heads up, I am not in favor of requiring users to dynamically generate .sln, .vcproj or .csproj files.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Thursday, July 17, 2008 1:37 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

On Tuesday 17 June 2008 13:01:17 Jason Birch wrote:
> Hi Helio (is that an OK form of address?),
>
> Any update on making the initial patch available?  I'd really like to
> see how this stuff works :)
>
> Jason

Ok, back from the darkness ( also know as managing a whole part from a future
linux distro release to be out in first alpha )

I sent two weeks the signed form about commits right ( by fax ) and finishing
the second buildsystem cleanup, based on trunk now.
windows build is been slowly introduced now, but for this i will need help
from widows guys too.
Instead of push the minor changes in code to avoid some unexpected surprises,
if gcc is detected the FORTIFY_SOURCE flags are added to gcc behaves as in old
< 4.3 releases.

I will upload the new version  as soon as i back from OSCON next week.

For who not seen the first version of buildsystem patches, they are here for
3.3.1: http://www.geolinux.com.br/

[]'s

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

[Jason Birch]

Hi Greg,

I think that Helio has already done most of the work for the RFC (other
than documentation?) as part of his effort creating FDO/MapGuide
packages for Mandriva.  As far as I can see, the patches do not remove
any of the existing files; and the RFC mentions that they can stay in
place with no ill effects during the transition.

One of the hopes that I had was that by having CMake generate the
Microsoft solution/project files, we could avoid the situation we saw
earlier with all developers having to move to VS2008 at one time.  Not
sure if this makes sense though.

Apart from that, I am entirely in favour of this RFC because I believe
that it will contribute to making FDO available across more platforms in
a package-friendly way.  If we can get any outstanding questions or
concerns wrapped up fairly soon (Greg, have you had a chance to look at
the patches?) I would love to see this move to a vote.

Jason

-----Original Message-----
From: Greg Boone
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake
Based

Hi Helio,

You should really get the RFC approved by the PSC before moving too far
ahead with the implementation. As a part of the RFC approval, you will
have to provide responses on how you have addressed the concerns I
originally voiced some time ago:

If the changes are submitted:

1) Can a full build, that includes FDO and all providers, be run in
batch, without the need for any FDO/Thirdparty components to be
installed?
2) Will new build routines for all FDO, providers and Utility projects
be supported as a part of the RFC code submission?
3) Will the build documentation be updated as a part of the submission?
4) How will build validation be performed?

I also recommend not deleting any existing build files as a part of your
eventual submission so that both build options can co-exist until all
the kinks are worked-out.

You also need to outline how the Windows build will be affected. Just to
give you a heads up, I am not in favor of requiring users to dynamically
generate .sln, .vcproj or .csproj files.

Greg
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Greg Boone]

As I see it, forcing our VS users to regenerate their project files from the CMake files is going to be a really tough sell. You can make it an option I suppose, but maintaining the VS 2008 project files is going to be a fairly important requirement from my perspective. However, in such a dual scenario I can see the CMake and VS files quickly getting out of sync.

I know that the current patches do not remove any existing files, but supporting two Linux build systems is not a practical solution. We will have to standardize on a single Linux build option in short order. In that light, who will guarantee that a full build, that includes FDO and all providers in SVN, be run in batch, without the need for any FDO/Thirdparty components to be installed?

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Thursday, July 17, 2008 4:59 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

Hi Greg,

I think that Helio has already done most of the work for the RFC (other
than documentation?) as part of his effort creating FDO/MapGuide
packages for Mandriva.  As far as I can see, the patches do not remove
any of the existing files; and the RFC mentions that they can stay in
place with no ill effects during the transition.

One of the hopes that I had was that by having CMake generate the
Microsoft solution/project files, we could avoid the situation we saw
earlier with all developers having to move to VS2008 at one time.  Not
sure if this makes sense though.

Apart from that, I am entirely in favour of this RFC because I believe
that it will contribute to making FDO available across more platforms in
a package-friendly way.  If we can get any outstanding questions or
concerns wrapped up fairly soon (Greg, have you had a chance to look at
the patches?) I would love to see this move to a vote.

Jason

-----Original Message-----
From: Greg Boone
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake
Based

Hi Helio,

You should really get the RFC approved by the PSC before moving too far
ahead with the implementation. As a part of the RFC approval, you will
have to provide responses on how you have addressed the concerns I
originally voiced some time ago:

If the changes are submitted:

1) Can a full build, that includes FDO and all providers, be run in
batch, without the need for any FDO/Thirdparty components to be
installed?
2) Will new build routines for all FDO, providers and Utility projects
be supported as a part of the RFC code submission?
3) Will the build documentation be updated as a part of the submission?
4) How will build validation be performed?

I also recommend not deleting any existing build files as a part of your
eventual submission so that both build options can co-exist until all
the kinks are worked-out.

You also need to outline how the Windows build will be affected. Just to
give you a heads up, I am not in favor of requiring users to dynamically
generate .sln, .vcproj or .csproj files.

Greg
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Greg Boone]

Actually, my question should probably have been:

"In that light, who will guarantee that a full build, that includes Thirdparty, FDO and all providers in SVN, be run in batch, without the need for any components to be installed?"

Also,

On Linux and Windows, how will you test build scenarios in which Zero, a subset or all Thirdparty/FDO components are installed.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Thursday, July 17, 2008 5:14 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

As I see it, forcing our VS users to regenerate their project files from the CMake files is going to be a really tough sell. You can make it an option I suppose, but maintaining the VS 2008 project files is going to be a fairly important requirement from my perspective. However, in such a dual scenario I can see the CMake and VS files quickly getting out of sync.

I know that the current patches do not remove any existing files, but supporting two Linux build systems is not a practical solution. We will have to standardize on a single Linux build option in short order. In that light, who will guarantee that a full build, that includes FDO and all providers in SVN, be run in batch, without the need for any FDO/Thirdparty components to be installed?

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Thursday, July 17, 2008 4:59 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

Hi Greg,

I think that Helio has already done most of the work for the RFC (other
than documentation?) as part of his effort creating FDO/MapGuide
packages for Mandriva.  As far as I can see, the patches do not remove
any of the existing files; and the RFC mentions that they can stay in
place with no ill effects during the transition.

One of the hopes that I had was that by having CMake generate the
Microsoft solution/project files, we could avoid the situation we saw
earlier with all developers having to move to VS2008 at one time.  Not
sure if this makes sense though.

Apart from that, I am entirely in favour of this RFC because I believe
that it will contribute to making FDO available across more platforms in
a package-friendly way.  If we can get any outstanding questions or
concerns wrapped up fairly soon (Greg, have you had a chance to look at
the patches?) I would love to see this move to a vote.

Jason

-----Original Message-----
From: Greg Boone
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake
Based

Hi Helio,

You should really get the RFC approved by the PSC before moving too far
ahead with the implementation. As a part of the RFC approval, you will
have to provide responses on how you have addressed the concerns I
originally voiced some time ago:

If the changes are submitted:

1) Can a full build, that includes FDO and all providers, be run in
batch, without the need for any FDO/Thirdparty components to be
installed?
2) Will new build routines for all FDO, providers and Utility projects
be supported as a part of the RFC code submission?
3) Will the build documentation be updated as a part of the submission?
4) How will build validation be performed?

I also recommend not deleting any existing build files as a part of your
eventual submission so that both build options can co-exist until all
the kinks are worked-out.

You also need to outline how the Windows build will be affected. Just to
give you a heads up, I am not in favor of requiring users to dynamically
generate .sln, .vcproj or .csproj files.

Greg
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals