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

[Greg Boone]

As I see it, we cannot assume that all Thirdparty components are installed. We will have to continue to support an option to build a subset or all of the components in the Thirdparty folder.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Thursday, July 17, 2008 5:22 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based


I think that (at least for Linux) the assumption is that the Thirdparty components are already there, just like today you can't build without having all the Thirdparty components. Why is there need to test the build when the components are not there -- obviously the build would fail in that case.

Traian


> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Greg Boone
> Sent: Thursday, July 17, 2008 5:19 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake
> Based
>
> 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: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] 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: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] 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
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals