clipka <ano### [at] anonymousorg> wrote:
> 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.

I would guess at some point you go to move to MSVC2012... 2014...  and have the
option to use CMake's project files or to create your own, at that point it may
be easy just to use the generated ones.

> 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.)

Is there a list of build environments you support? or do you just mean IDE/OS
configuration?

> 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.

Sounds good.

Ill check on this when I get some free time (weekends probably).

As for output, its common for cmake projects not to do (or allow) in-source
builds, so developers create their own build dir and that references the source
path. makes it very convenient to debug/release intel/clang/gcc... etc compilers
all pointing to the same build.

At first this seemed annoying to me but now I much prefer it since you dont mix
up build files in your source dir.

If others have a strong opinion in-source builds can be supported, but this
isn't really that big of a deal and can be changed later.

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

Only curious if there is anything thats nonstandard going on or any code
generation.

Post a reply to this message