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

Thu Jul 17 18:07:00 EDT 2008

One additional point. In such a system, I think we would also need to develop, build and post (as a part of the standard build process) a Linux RPM-ish distribution mechanism for FDO and each provider.

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 6:02 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake Based

Yes, the reason why I think getting rid of 3rd party is that using already-installed 3rd party would actually reduce the support overhead due to the following:

(1) people using a compiler which errors out when compiling some of the components -- currently they come to us for support since build_thirdparty is our script.
(2) people using a configuration that we have not tried, like 64 bit builds on Linux. In the past we have had people get failure in 64 bit builds of 3rd party components since we had older versions of these components in our vault. Those people also come to us in such cases.

If you guys think that this overhead is smaller than the overhead we'd get if we told people to go get their missing library, then yes, this would not be worth it.

However, another thing to consider is that having the build system independent of 3rd party stuff makes it far easier to distribute FDO using the standard Linux distribution repositories -- this would help adoption, I think, and may be worth some pain.

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:53 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake
> Based
>
> While removing all the Thirdparty build requirements would be ideal, I
> am just envisioning the support requirements from our developers/users.
> If the community is willing to step up to the plate to help all those
> individuals who will have questions on how and what to install, then
> there may be a possibility here. But that is a big If. I would also
> think that such a change would have to happen as a part of moving the
> Linux build onto a non-Autodesk build machine and automating a build-
> bot, daily-build, weekly-build, auto-posting process.
>
> 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:31 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] FDO RFC 21 - New Linux Buildsystem Cmake
> Based
>
>
> 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
> _______________________________________________
> 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