Am 14.11.2013 13:51, schrieb ideasman42:

> Point taken, I cant argue with this - on the other hand there is no need to drop
> MSVC project files instantly either until you are OK with the CMake generated
> ones (or never if you prefer not to use them).
> The advantage with them is you can easily support many MSVC versions at once,
> which IIRC isnt totally simple otherwise, but I dont use msvc.

As a matter of fact this happens to be the reason why we dropped support 
for VS 2005 and 2008: Nobody of us used those environments as primary 
development environment anymore, and the change in project file 
structure from 2008 to 2010 was too severe to easily back-port 
modifications to the VS2010 project files.

Another thing that's less than perfect is that when changing the 
settings for one of the multiple build targets (Win32, Win32-SSE, x64, 
Win32-Debug and x64-Debug) or one of the sub-projects (frontend, 
backend, gui, etc.) it's easy to forget to update the others along.


> As for weather I would maintain this - well yes, but once its written (and some
> developers use it) I expect it wouldnt be the only person having to maintain
> anyway-  others notice if it breaks and fix things too, unless you start adding
> code new generators and new languages - I expect maintaining would be very
> little effort.

Sounds like a fair deal to me.

To go ahead, I would suggest you pull the Git repository, set up the 
CMake thing for one particular build environment to start with 
(preferably one we're not currently supporting yet, so we have some 
benefit right from the start), and once you manage to compile & run 
POV-Ray with it, contact Chris on details how to submit it to the 
POV-Ray repository. (Using Git for public access to the repository is 
brand new to us, so we may need to get used to the workflow.)

Make sure to place everything you add into a separate directory, such as 
"./cmake". Inside there, I guess everything is fair game, except that 
generated and temporary files should go into (sub-)directories of their 
own, to simplify both revision control and finding the output. Maybe one 
output directory per build environment would be best.

In case you have questions about the source tree structure or other 
project peculiarities, don't hesitate to shout.

Post a reply to this message