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

[Traian Stanev]

In the case of Linux, all other Linux apps assume that. It's the way Linux works. Besides, do you really want to maintain builds of all those apps? We aren't the Apache maintainers or the GDAL maintainers, why should we maintain builds of those projects? People would automatically have (or be able to get) builds of these projects that are appropriate to their system using their package manager.

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:27 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake
> Based
>
> 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
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals