Hi, I read on the recent github page that supporting IDE's (not just MSVC) is
high priority for Povray.

I maintain CMake build-system for Blender and have found it excellent for
MSVC/Eclipse/QtCreator/Netbeans/KDevelop (XCode works well apparently though I
don't use OSX).

This also allows you to use Ninja (rather then gnu-make) which can give very
fast builds.


While the syntax of the CMake is a little strange, overall the build system
works very well in my experience, other projects such as LLVM/Clang, BRL-CAD,
OpenImageIO, OpenShadingLanguage - are using CMake too.

Is it worth me getting CMake setup for Povray? - if you guys are not interested
I would rather not spend time on it.

Post a reply to this message

Le 14/11/2013 08:49, ideasman42 a écrit :
> Hi, I read on the recent github page that supporting IDE's (not just MSVC) is
> high priority for Povray.
> 
> I maintain CMake build-system for Blender and have found it excellent for
> MSVC/Eclipse/QtCreator/Netbeans/KDevelop (XCode works well apparently though I
> don't use OSX).
> 
> This also allows you to use Ninja (rather then gnu-make) which can give very
> fast builds.
> 
> 
> While the syntax of the CMake is a little strange, overall the build system
> works very well in my experience, other projects such as LLVM/Clang, BRL-CAD,
> OpenImageIO, OpenShadingLanguage - are using CMake too.
> 
> Is it worth me getting CMake setup for Povray? - if you guys are not interested
> I would rather not spend time on it.

My 0.02c:
 1. Is the gnu-make broken ? Do not fix unless it's broken.
 2. From experience with eclipse, povray is rather "simple": compile
everything that is relevant and link as a single binary (smart part is
excluding from hierarchy the porting part that are not relevant to the
target)
 3. Fast build: I do not care, I build 6 different version of povray on
my home system (3 compilers(gcc, clang and intel), official and personal
code) and that might happen only once per month or less (but I enjoy
"make -j 15" for the speedup... but that's my system). When I'm in a
loop of compilation, usually it's for a new extension, and make only
recompile what has been touched. (until it reachs my syntax error)
 4. The tricky part is mainly running configure when extracting the
tarball, nothing related to makefile.

Now, the previous points apply to a unix/linux system.

I do not know if the Windows part is happy with the MSVC projects (or
whatever they now named the IDE). But the official one has graphical
interface not available in unix, so factoring on makefile seems futile.

On my linux usage, there is basically a single target for make: generate
the binary. All others secondary target are, to me, mainly irrelevant
(make, make clean and make distclean is basically all I need. Sometime
make check, and make install)

I do not know for the Mac port either, which so far is kindly provided
by Yvo Smellenbergh.

-- 
Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message

Am 14.11.2013 08:49, schrieb ideasman42:
> Hi, I read on the recent github page that supporting IDE's (not just MSVC) is
> high priority for Povray.
>
> I maintain CMake build-system for Blender and have found it excellent for
> MSVC/Eclipse/QtCreator/Netbeans/KDevelop (XCode works well apparently though I
> don't use OSX).
>
> This also allows you to use Ninja (rather then gnu-make) which can give very
> fast builds.
>
>
> While the syntax of the CMake is a little strange, overall the build system
> works very well in my experience, other projects such as LLVM/Clang, BRL-CAD,
> OpenImageIO, OpenShadingLanguage - are using CMake too.
>
> Is it worth me getting CMake setup for Povray? - if you guys are not interested
> I would rather not spend time on it.

A much more relevant question here is, are /you/ interested in a CMake 
setup for POV-Ray? Would you use it yourself?

If you are, then chances are there's probably someone else out there who 
would use it as well.

If you aren't, then chances are you'll lose motivation to maintain it in 
the long run.

Setting up make files for a particular build system is just the smallest 
part of the job; keeping them alive and kicking over the years for an 
ever changing piece of software is the real challenge.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Le 14/11/2013 08:49, ideasman42 a écrit :
> > Hi, I read on the recent github page that supporting IDE's (not just MSVC) is
> > high priority for Povray.
> >
> > I maintain CMake build-system for Blender and have found it excellent for
> > MSVC/Eclipse/QtCreator/Netbeans/KDevelop (XCode works well apparently though I
> > don't use OSX).
> >
> > This also allows you to use Ninja (rather then gnu-make) which can give very
> > fast builds.
> >
> >
> > While the syntax of the CMake is a little strange, overall the build system
> > works very well in my experience, other projects such as LLVM/Clang, BRL-CAD,
> > OpenImageIO, OpenShadingLanguage - are using CMake too.
> >
> > Is it worth me getting CMake setup for Povray? - if you guys are not interested
> > I would rather not spend time on it.
>
> My 0.02c:
>  1. Is the gnu-make broken ? Do not fix unless it's broken.

gnu-make works fine.

>  2. From experience with eclipse, povray is rather "simple": compile
> everything that is relevant and link as a single binary (smart part is
> excluding from hierarchy the porting part that are not relevant to the
> target)

Yep, CMake can do this, only include paths that are build in the projectfiles,
sometimes I just load in all source though since it can be better for
refactoring not to miss function calls on other platforms --- this may be a bit
personal preference too.

>  3. Fast build: I do not care, I build 6 different version of povray on
> my home system (3 compilers(gcc, clang and intel), official and personal
> code) and that might happen only once per month or less (but I enjoy
> "make -j 15" for the speedup... but that's my system). When I'm in a
> loop of compilation, usually it's for a new extension, and make only
> recompile what has been touched. (until it reachs my syntax error)

I think you missed my point, Its not that gnu-make is bad, rather using CMake
(which is a meta-buildsystem which generates build files for make/ninja/msvc)
means you're not tied to using one and can get the benefits of other
buildsystems, even though speed may not be an issue its still nice to use a fast
buildsystem in my experience.

>  4. The tricky part is mainly running configure when extracting the
> tarball, nothing related to makefile.
>
> Now, the previous points apply to a unix/linux system.
>
> I do not know if the Windows part is happy with the MSVC projects (or
> whatever they now named the IDE). But the official one has graphical
> interface not available in unix, so factoring on makefile seems futile.

Done well, CMake can be used to generate MSVC project files to save you the
hassle of maintaining them and committing them into your source.

> On my linux usage, there is basically a single target for make: generate
> the binary. All others secondary target are, to me, mainly irrelevant
> (make, make clean and make distclean is basically all I need. Sometime
> make check, and make install)
>
> I do not know for the Mac port either, which so far is kindly provided
> by Yvo Smellenbergh.


Well, I wrote this because I read that IDE support was important but I get the
impression you personally dont think so?

Nevertheless - Just because you may not need all that CMake offers, if nothing
else it still saves you from having to maintain makefiles and msvc project files
(which can be a pain when you consider different versions of MSVC need their own
project files).
IDE support is an added bonus but you can ignore it too if its not interesting
to you.


I rather not try to convince povray devs too much, I just thought I could set
this up over a weekend if you guys are interested - and help maintain a little
until Povray devs get the hang of things.

> --
> Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message

Am 14.11.2013 11:01, schrieb ideasman42:

>> I do not know if the Windows part is happy with the MSVC projects (or
>> whatever they now named the IDE). But the official one has graphical
>> interface not available in unix, so factoring on makefile seems futile.
>
> Done well, CMake can be used to generate MSVC project files to save you the
> hassle of maintaining them and committing them into your source.

While that may well be true, and is probably a big benefit for projects 
that have their origins outside the Windows world, it may actually be 
counter-productive in a project like POV-Ray where MSVC happens to be 
the primary development environment, and where the primary developers 
don't have much CMake experience themselves. I see a risk here that it 
would create a dependency on external expertise, which in a hobbyist 
project cannot be guaranteed to persist.

Now if a CMake setup would be started by someone with enough personal 
motivation to carry it through its infancy and push it to a high level 
of quality, switching over to CMake as the primary build system might at 
some time become a viable and productive option; it's not like 
maintaining native MSVC project files is a perfect solution. But if this 
would be your only reason to set up a CMake system, then don't do it.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 14.11.2013 11:01, schrieb ideasman42:
>
> >> I do not know if the Windows part is happy with the MSVC projects (or
> >> whatever they now named the IDE). But the official one has graphical
> >> interface not available in unix, so factoring on makefile seems futile.
> >
> > Done well, CMake can be used to generate MSVC project files to save you the
> > hassle of maintaining them and committing them into your source.
>
> While that may well be true, and is probably a big benefit for projects
> that have their origins outside the Windows world, it may actually be
> counter-productive in a project like POV-Ray where MSVC happens to be
> the primary development environment, and where the primary developers
> don't have much CMake experience themselves. I see a risk here that it
> would create a dependency on external expertise, which in a hobbyist
> project cannot be guaranteed to persist.

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.

> Now if a CMake setup would be started by someone with enough personal
> motivation to carry it through its infancy and push it to a high level
> of quality, switching over to CMake as the primary build system might at
> some time become a viable and productive option; it's not like
> maintaining native MSVC project files is a perfect solution. But if this
> would be your only reason to set up a CMake system, then don't do it.

Yep gradual migration is fine, for blender at one point we have ~5 or so
buildsystems, it was horrible.
- scons
- hand written makefiles
- cmake
- msvc (2 versions)
- autoconf/automake (not sure it ever worked well)

We managed to remove hand written makefiles and MSVC project files and replace
with CMake.


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.

Post a reply to this message

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

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

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

On 11/14/2013 07:51 AM, ideasman42 wrote:
<snip>
> - autoconf/automake (not sure it ever worked well)

well I'll watch you efforts with interest ... I'd like to see the 
unix/linux build process cleaned up. I tired several times but was never 
able to spend enough time with it to make any headway.

Post a reply to this message