As a follow up to this question, I would prefer that the CMakeLists are the only things in the repository. Some of my co-workers are a little nervous about the workflow. I proposed to them that anytime a sync is done to the repository code base, one should open up the cmake gui and rebuild the solutions and projects just in case something changed. (versus looking through the sync results and checking to see if a cmakelists got modified). Just get into a habit of doing it.
So the concern is that the process will take too long. Our code base clocks in to at least 500,000 lines of code with many different projects. I know KDE has successfully moved to cmake for the kdelibs so I was hoping to get some feedback on how much time it takes cmake to generate the resulting projects/solutions and/or makefiles given a large code base. Thanks. -Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Campbell Sent: Wednesday, October 18, 2006 1:08 PM To: Brad King Cc: [email protected] Subject: RE: [CMake] Forcing vc guiids to be the same Understood. Thanks for the info guys. -Matt -----Original Message----- From: Brad King [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 12:45 PM To: Matthew Campbell Cc: [email protected] Subject: Re: [CMake] Forcing vc guiids to be the same Matthew Campbell wrote: > I was wondering if there was any way to instruct cmake to generate the > same guid's for Microsoft projects and solution files? We would like to > have the option of putting the solutions and projects in source control > but this poses a problem since the guids are regenerated and differ each > time. FYI, putting the CMake-generated build system under source control is not a supported use case. In order to build anything non-trivial CMake has to be on the system where the build occurs. -Brad _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
