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