Am 14.11.2013 16:30, schrieb ideasman42:
> 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?

When I say "build environment", I mean the tools available for compiling 
and linking.

On Windows we currently provide full support only for MS Visual Studio 
2010 with the native VS2010 toolset.

On GNU/Linux we currently provide support primarily for gcc, though icpc 
can also be used. clang hasn't been tested yet as far as I know.

An interesting project might be to implement support for some Windows 
build environment other than MS Visual Studio, preferably a free one, 
with the goal that users can compile their own version of POV-Ray 
without having to acquire a license for Microsoft's proprietary software.

> 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-source builds suck anyway :-P


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

Currently there's no code generation from POV-Ray itself, but some 
libraries generate config files as part of their build process (IIRC 
this is the case for libtiff and libpng), or even build & run small 
software tools to generate code (this is the case for OpenEXR).

For POV-Ray's Windows UI there are two separate DLL projects, one of 
which isn't part of the official 3.7.0 release due to licensing issues.

Aside from that it's just compile, link & run.

Ah, and there's a deliberate compile error you will bump into if you 
forget to set some preprocessor macros intended to identify the 
individual responsible for the (presumably unofficial) build.

Post a reply to this message