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. > 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. :) > I can't specifically recall why I used both CMAKE_CL_64 and > CMAKE_SIZEOF_VOID_P, but I have a nagging feeling that it was to work > around something. I would not change that without verifying that it > doesn't break one of the configurations. Part of the trickiness on > Windows comes from the fact that CMake has to be able to generate Visual > Studio projects, and when you are generating a Visual Studio project, > the compiler may or may not be accessible from the command line on which > you are running CMake. I suspect that this is why CMAKE_CL_64 is there. > CMAKE_SIZEOF_VOID_P has to run the compiler, whereas CMAKE_CL_64 > perhaps can detect whether you are using a 64-bit environment in the > Visual Studio IDE. I am not certain of that, however. > I think we have to assume that we have access to the compiler. Otherwise the use of CMake (or any general build system) becomes rather pointless as we cannot test for features and bugs. At that point we might as well check in Visual Studio project files. As for the matter at hand, I don't like having magic in the build system that we do not know why it's there. I'll commit a change to VOID_P and we'll see if and how it breaks the build. Then we can at least document why we need the hack. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
