On Tue, Mar 08, 2011 at 01:06:03PM +0100, Pierre Ossman wrote:
> On Fri, 04 Mar 2011 17:35:45 -0600
> DRC <dcomman...@users.sourceforge.net> wrote:
> 
> > It is what it is.  My position has always been that integrating
> > everything under CMake would be a tricky process requiring potentially
> > hundreds of hours to get exactly right on all the platforms we care
> > about, and the resulting system would likely be more fragile than the
> > autotools build system.  This is why I advocated keeping the Unix build
> > system separate.
> 
> Well, we've tried the dual build system approach in the past and it
> didn't really work. As far as I'm concerned we have two options on the
> table; going on ahead with using CMake for everything and dealing with
> the fallout, or scrapping CMake and going back to autotools.

+1 for CMake-only buildsys even if development on it might sometimes
break buildsystem on certain platforms. If it happens it should be
reported same way as DRC did it in the MinGW case.

> > The bulk of the time I spent on doing the Windows
> > CMake build system was spent regression testing, and there is no
> > substitute for that.  I consider the odds quite high that any major
> > change made in the future to the CMake build system will break at least
> > one configuration we care about.  CMake has some very esoteric
> > behaviors, and it's been my experience that often things just simply do
> > not work as documented, so a good percentage of our CMake code is there
> > because it was needed to work around something in CMake that was broken.
> 
> I have no doubt that all the changes planned will break things
> somewhere. That's why I'm trying to get most of the changes in now so
> that we have a lot of time to find any problems. :)

Proverb "You can't make an omelet without breaking eggs" is annoying
but is also right.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel

Reply via email to