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

Le 14/11/2013 17:19, clipka nous fit lire :
> clang hasn't been tested yet as far as I know.

Well, not officially, but I did build with clang 3.2 and 3.3 (povray 3.7RC7)

Build details at
> http://wiki.povray.org/content/User:Le_Forgeron/vault/Compilation

So far, for my cpu, icpc is best. clang 3.3 improved a bit when compared
to 3.2, but still not to the level of gcc when HT is in the figure (but
clang is better than gcc when there is no HT)

Post a reply to this message

James Holsenback <nom### [at] nonecom> wrote:
> 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.

Heres the initial effort to support CMake.

Eclipse project file:
 - http://www.graphicall.org/ftp/ideasman42/linux_eclipse_povray.png

Clang3.3 output:
 - http://www.graphicall.org/ftp/ideasman42/linux_clang33_povray.html

Currently its a single CMakeLists.txt file, which should be broken up, and
theres TODO's listed at the top of the file.


Git repo:
- https://github.com/ideasman42/povray-cmake

Post a reply to this message

ideasman42 wrote:
> James Holsenback <nom### [at] nonecom> wrote:
>> 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.
> 
> Heres the initial effort to support CMake.
> 
> Currently its a single CMakeLists.txt file, which should be broken up, and
> theres TODO's listed at the top of the file.
> 
> Git repo:
> - https://github.com/ideasman42/povray-cmake

I'm looking into writing a CMake build system too. I'm not really using your 
effort as a base, but considering your list of TODOs it would need almost a 
rewrite anyway. For example, I'm starting straight away with an explicit 
list of sources instead of globs :)

Post a reply to this message

Le 07/03/2014 22:40, Nicolas Alvarez nous fit lire :
> ideasman42 wrote:
>> Heres the initial effort to support CMake.
>>
>> Currently its a single CMakeLists.txt file, which should be broken up, and
>> theres TODO's listed at the top of the file.
>>
>> Git repo:
>> - https://github.com/ideasman42/povray-cmake
> 
> I'm looking into writing a CMake build system too. I'm not really using your 
> effort as a base, but considering your list of TODOs it would need almost a 
> rewrite anyway. For example, I'm starting straight away with an explicit 
> list of sources instead of globs :)
> 
So, whenever adding a new source file, you also have to know about that
list ? What about the dependencies ? Do you use a Chinese army approach ?

Post a reply to this message

Le_Forgeron wrote:
> Le 07/03/2014 22:40, Nicolas Alvarez nous fit lire :
>> I'm looking into writing a CMake build system too. I'm not really using
>> your effort as a base, but considering your list of TODOs it would need
>> almost a rewrite anyway. For example, I'm starting straight away with an
>> explicit list of sources instead of globs :)
>> 
> So, whenever adding a new source file, you also have to know about that
> list ? What about the dependencies ? Do you use a Chinese army approach ?

When you add a new source file, you need to modify the build system. I don't 
see how that's surprising.

Assuming you mean #include dependencies, they are are handled automatically.
The simplest CMake script is:

add_executable(myprogram one.cpp two.cpp three.cpp)

You don't need to say what header files they depend on.

Post a reply to this message

Am 08.03.2014 20:09, schrieb Nicolas Alvarez:
> Le_Forgeron wrote:
>> Le 07/03/2014 22:40, Nicolas Alvarez nous fit lire :
>>> I'm looking into writing a CMake build system too. I'm not really using
>>> your effort as a base, but considering your list of TODOs it would need
>>> almost a rewrite anyway. For example, I'm starting straight away with an
>>> explicit list of sources instead of globs :)
>>>
>> So, whenever adding a new source file, you also have to know about that
>> list ? What about the dependencies ? Do you use a Chinese army approach ?
>
> When you add a new source file, you need to modify the build system. I don't
> see how that's surprising.

FYI, the current Automake build system does /not/ need any modifications 
upon addition of a new source file. It simply builds all source files in 
a given set of directories.

Post a reply to this message

In his project, I want to use the Povray. I can not study very long
configuration files.
I decided to use CMake.
To build the project in Linux, I wrote a single file CMakeLists.txt

cmake_minimum_required(VERSION 2.8)

project(povanim)


set(CMAKE_CXX_FLAGS "-std=c++11 -pipe -Wno-multichar -Wno-write-strings
-fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math -march=native
-pthread")


set( SOURCE_ROOT                    source )
set( SOURCE_BASKEND                 source/backend )
set( SOURCE_BASKEND_BOUNDING        source/backend/bounding )
set( SOURCE_BASKEND_CONTROL         source/backend/control )
set( SOURCE_BASKEND_LIGHTING        source/backend/lighting )
set( SOURCE_BASKEND_RENDER          source/backend/render )
set( SOURCE_BASKEND_SCENE           source/backend/scene )
set( SOURCE_BASKEND_SUPPORT         source/backend/support )
set( SOURCE_BASE                    source/base )
set( SOURCE_BASE_ANIMATION          source/base/animation )
set( SOURCE_BASE_FONT               source/base/font )
set( SOURCE_BASE_IMAGE              source/base/image )
set( SOURCE_CORE                    source/core )
set( SOURCE_CORE_BOUNDING           source/core/bounding )
set( SOURCE_CORE_COLOUR             source/core/colour )
set( SOURCE_CORE_LIGHTING           source/core/lighting )
set( SOURCE_CORE_MATERIAL           source/core/material )
set( SOURCE_CORE_MATH               source/core/math )
set( SOURCE_CORE_RENDER             source/core/render )
set( SOURCE_CORE_SCENE              source/core/scene )
set( SOURCE_CORE_SHAPE              source/core/shape )
set( SOURCE_CORE_SUPPORT            source/core/support )
set( SOURCE_FRONTEND                source/frontend )
set( SOURCE_PARSER                  source/parser )
set( SOURCE_POVMS                   source/povms )
set( SOURCE_VM                      source/vm )
set( SOURCE_UNIX                    unix )
set( SOURCE_PLATFORM_UNIX           platform/unix )
set( SOURCE_PLATFORM_X86            platform/x86)
set( SOURCE_VFE                     vfe )
set( SOURCE_VFE_UNIX                vfe/unix)


aux_source_directory( ${SOURCE_ROOT}                     SOURCEROOT )
aux_source_directory( ${SOURCE_BASKEND}                  SOURCEBASKEND )
aux_source_directory( ${SOURCE_BASKEND_BOUNDING}         SOURCEBASKENDBOUNDING )
aux_source_directory( ${SOURCE_BASKEND_CONTROL}          SOURCEBASKENDCONTROL )
aux_source_directory( ${SOURCE_BASKEND_LIGHTING}         SOURCEBASKENDLIGHTING )
aux_source_directory( ${SOURCE_BASKEND_RENDER}           SOURCEBASKENDRENDER )
aux_source_directory( ${SOURCE_BASKEND_SCENE}            SOURCEBASKENDSCENE )
aux_source_directory( ${SOURCE_BASKEND_SUPPORT}          SOURCEBASKENDSUPPORT )
aux_source_directory( ${SOURCE_BASE}                     SOURCEBASE )
aux_source_directory( ${SOURCE_BASE_ANIMATION}           SOURCEBASEANIMATION )
aux_source_directory( ${SOURCE_BASE_FONT}                SOURCEBASEFONT )
aux_source_directory( ${SOURCE_BASE_IMAGE}               SOURCEBASEIMAGE )
aux_source_directory( ${SOURCE_CORE}                     SOURCECORE )
aux_source_directory( ${SOURCE_CORE_BOUNDING}            SOURCECOREBOUNDING )
aux_source_directory( ${SOURCE_CORE_COLOUR}              SOURCECORECOLOUR )
aux_source_directory( ${SOURCE_CORE_LIGHTING}            SOURCECORELIGHTING )
aux_source_directory( ${SOURCE_CORE_MATERIAL}            SOURCECOREMATERIAL )
aux_source_directory( ${SOURCE_CORE_MATH}                SOURCECOREMATH )
aux_source_directory( ${SOURCE_CORE_RENDER}              SOURCECORERENDER )
aux_source_directory( ${SOURCE_CORE_SCENE}               SOURCECORESCENE )
aux_source_directory( ${SOURCE_CORE_SHAPE}               SOURCECORESHAPE )
aux_source_directory( ${SOURCE_CORE_SUPPORT}             SOURCECORESUPPORT )
aux_source_directory( ${SOURCE_FRONTEND}                 SOURCEFRONTEND )
aux_source_directory( ${SOURCE_PARSER}                   SOURCEPARSER )
aux_source_directory( ${SOURCE_POVMS}                    SOURCEPOVMS )
aux_source_directory( ${SOURCE_VM}                       SOURCEVM )
aux_source_directory( ${SOURCE_UNIX}                     SOURCEUNIX )
aux_source_directory( ${SOURCE_PLATFORM_UNIX}            SOURCEPLATFORMUNIX )
aux_source_directory( ${SOURCE_PLATFORM_X86}             SOURCEPLATFORMX86 )
aux_source_directory( ${SOURCE_VFE}                      SOURCEVFE )
aux_source_directory( ${SOURCE_VFE_UNIX}                 SOURCEVFEUNIX )

find_package(           JPEG REQUIRED)
find_package(           PNG REQUIRED)
find_package(           PkgConfig REQUIRED)

pkg_search_module(      SDL REQUIRED sdl)

set( UNIX_POVCONFIG_INCLUDE_DIR unix/povconfig)

include_directories(    ${SOURCE_ROOT}
                        ${SOURCE_BASKEND}
                        ${SOURCE_BASE}
                        ${SOURCE_CORE}
                        ${SOURCE_FRONTEND}
                        ${SOURCE_PARSER}
                        ${SOURCE_POVMS}
                        ${SOURCE_VM}
                        ${SOURCE_UNIX}
                        ${UNIX_POVCONFIG_INCLUDE_DIR}
                        ${SOURCE_PLATFORM_UNIX}
                        ${SOURCE_PLATFORM_X86}
                        ${SOURCE_VFE}
                        ${SOURCE_VFE_UNIX}
                        ${SDL_INCLUDE_DIRS}
                        ${JPEG_INCLUDE_DIRS}
                        ${PNG_INCLUDE_DIRS}
                        )

add_executable(         ${PROJECT_NAME}
                        ${SOURCEROOT}
                        ${SOURCEBASKEND}
                        ${SOURCEBASKENDBOUNDING}
                        ${SOURCEBASKENDCONTROL}
                        ${SOURCEBASKENDLIGHTING}
                        ${SOURCEBASKENDRENDER}
                        ${SOURCEBASKENDSCENE}
                        ${SOURCEBASKENDSUPPORT}
                        ${SOURCEBASE}
                        ${SOURCEBASEANIMATION}
                        ${SOURCEBASEFONT}
                        ${SOURCEBASEIMAGE}
                        ${SOURCECORE}
                        ${SOURCECOREBOUNDING}
                        ${SOURCECORECOLOUR}
                        ${SOURCECORELIGHTING}
                        ${SOURCECOREMATERIAL}
                        ${SOURCECOREMATH}
                        ${SOURCECORERENDER}
                        ${SOURCECORESCENE}
                        ${SOURCECORESHAPE}
                        ${SOURCECORESUPPORT}
                        ${SOURCEFRONTEND}
                        ${SOURCEPARSER}
                        ${SOURCEPOVMS}
                        ${SOURCEVM}
                        ${SOURCEUNIX}
                        ${SOURCEPLATFORMUNIX}
                        ${SOURCEPLATFORMX86}
                        ${SOURCEVFE}
                        ${SOURCEVFEUNIX}
                        )


target_link_libraries(  ${PROJECT_NAME}
                        ${SDL_LIBRARIES}
                        ${JPEG_LIBRARIES}
                        )

Not all external library I added, but JPEG FOUND

leonid@lanucomp ~/workspace/programming/povray_animator/povray $ LC_ALL=C make
Scanning dependencies of target povanim
[  0%] Building CXX object CMakeFiles/povanim.dir/source/pov_mem.cpp.o
[  1%] Building CXX object CMakeFiles/povanim.dir/source/povmain.cpp.o
[  1%] Building CXX object CMakeFiles/povanim.dir/source/backend/povray.cpp.o
/home/leonid/workspace/programming/povray_animator/povray-master/source/backend/povray.cpp:69:30:
fatal error: jversion.h: No such file or directory
         #include <jversion.h>
                              ^
compilation terminated.
CMakeFiles/povanim.dir/build.make:110: recipe for target
'CMakeFiles/povanim.dir/source/backend/povray.cpp.o' failed
make[2]: *** [CMakeFiles/povanim.dir/source/backend/povray.cpp.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/povanim.dir/all' failed
make[1]: *** [CMakeFiles/povanim.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
leonid@lanucomp ~/workspace/programming/povray_animator/povray $

In file povray.cpp:
    #ifndef LIBJPEG_MISSING
        #include <jversion.h>
    #endif

Povray does not use an external library libjpeg????
jpeg-devel package has only these files:
   /usr/include/jconfig.h
   /usr/include/jerror.h
   /usr/include/jmorecfg.h
   /usr/include/jpegint.h
   /usr/include/jpeglib.h
   /usr/include/turbojpeg.h
   /usr/lib64/libjpeg.so
   /usr/lib64/libturbojpeg.so

Post a reply to this message

All very good. :)

leonid@lanucomp ~/workspace/programming/povray_animator/povray $ LC_ALL=C make
-j4
Scanning dependencies of target povray
[  0%] Building CXX object CMakeFiles/povanim.dir/source/pov_mem.cpp.o
.....
.....
[ 99%] Building CXX object CMakeFiles/povanim.dir/vfe/unix/vfeplatform.cpp.o
[100%] Linking CXX executable povray
[100%] Built target povray
leonid@lanucomp ~/workspace/programming/povray_animator/povray $

Post a reply to this message

Am 09.10.2016 um 11:57 schrieb LanuHum:

> To build the project in Linux, I wrote a single file CMakeLists.txt
...

> set( SOURCE_ROOT                    source )
> set( SOURCE_BASKEND                 source/backend )
> set( SOURCE_BASKEND_BOUNDING        source/backend/bounding )
> set( SOURCE_BASKEND_CONTROL         source/backend/control )
> set( SOURCE_BASKEND_LIGHTING        source/backend/lighting )
> set( SOURCE_BASKEND_RENDER          source/backend/render )
> set( SOURCE_BASKEND_SCENE           source/backend/scene )
> set( SOURCE_BASKEND_SUPPORT         source/backend/support )
...
Isn't that overly verbose? Can't CMake build the contents of an entire
directory tree recursively?

(I guess for your own project you're probably ok with this for now, but
I'm also interested in exploring the potential of CMake for official
POV-Ray, so since you're toying around with CMake anyway, I'd be
grateful if you could investigate a bit further in that direction.)


> fatal error: jversion.h: No such file or directory
>          #include <jversion.h>
...
> Povray does not use an external library libjpeg????
> jpeg-devel package has only these files:
>    /usr/include/jconfig.h
>    /usr/include/jerror.h
>    /usr/include/jmorecfg.h
>    /usr/include/jpegint.h
>    /usr/include/jpeglib.h
>    /usr/include/turbojpeg.h
>    /usr/lib64/libjpeg.so
>    /usr/lib64/libturbojpeg.so

Historically, POV-Ray has been using the contents of `jversion.h` to
determine the version of libjpeg it reports to the end user in the list
of library copyright notices.

This works fine with the Windows version, since it is linked to the
version of libjpeg we're distributing in source code format along with
the POV-Ray for Windows source code; but as you have noticed correctly,
the file is typically unavailable for Unix builds as our Unix build
process nowadays always relies on an external libjpeg (disabling JPEG if
such an external library is unavailable).

In our automake-based Unix build process, this has been worked around by
faking the file, with information obtained by the automake tools via
other means.


I had never investigated this before, but now that I've looked at it I
consider it a bug, or at least a flaw that should (and can) be fixed. I
suspect it might be some artifact from the history of libjpeg. After
all, POV-Ray is in some sense 5 years older than libjpeg, and there may
have been times when `jversion.h` used to be the only file from which
version information could be obtained.

All versions of libjpeg that POV-Ray is still compatible with appear to
provide version information in `jpeglib.h`, and I've just made sure
that's the source future versions of POV-Ray will get their version
information from.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 09.10.2016 um 11:57 schrieb LanuHum:
>
> > To build the project in Linux, I wrote a single file CMakeLists.txt
> ...
>
> > set( SOURCE_ROOT                    source )
> > set( SOURCE_BASKEND                 source/backend )
> > set( SOURCE_BASKEND_BOUNDING        source/backend/bounding )
> > set( SOURCE_BASKEND_CONTROL         source/backend/control )
> > set( SOURCE_BASKEND_LIGHTING        source/backend/lighting )
> > set( SOURCE_BASKEND_RENDER          source/backend/render )
> > set( SOURCE_BASKEND_SCENE           source/backend/scene )
> > set( SOURCE_BASKEND_SUPPORT         source/backend/support )
> ...
> Isn't that overly verbose? Can't CMake build the contents of an entire
> directory tree recursively?
>
> (I guess for your own project you're probably ok with this for now, but
> I'm also interested in exploring the potential of CMake for official
> POV-Ray, so since you're toying around with CMake anyway, I'd be
> grateful if you could investigate a bit further in that direction.)
>

My problem - poor understanding of English.
No information in Russian.
Russian-speaking programmers write in English.
I hardly found aux_source_directory. :)))))
Usually written CMakeLists.txt for each directory.
But I do not think a large file.
This is much less than: configure.in, configure.ac, makefile.in, prebuild.sh,
bootstrap, makefile and so on.
Yes, I got ready config.h and the source code has disabled some functions.
I need to understand more.

Post a reply to this message

For example, the structure is different from the master and hgpovray.
Now I understand why stupid written configuration files gnumake.
CMakeListsGenerator.py

import os,sys

external_library = ['SDL','ILMBASE','OPENEXR','JPEG','PNG','TIFF']
pkg_modules = ['sdl','IlmBase','OpenEXR','libtiff-4']
cmake_names = ['SDL','ILMBASE','OPENEXR','TIFF']
cmake_packages = ['PkgConfig','JPEG','PNG']

cmakelist = open('CMakeLists.txt','w')
cmakelist.write('cmake_minimum_required(VERSION 2.8)\n\n')
cmakelist.write('project(povanim)\n\n')
if sys.platform in {'linux'}:
    cmakelist.write('set( CMAKE_CXX_FLAGS "-pipe -Wno-multichar \\\n')
    cmakelist.write('   -Wno-write-strings -fno-enforce-eh-specs \\\n')
    cmakelist.write('   -Wno-non-template-friend -s -O3 \\\n')
    cmakelist.write('   -ffast-math -march=native -pthread")\n\n')

sources = {}
unix_source_folders = {'source', 'platform', 'unix', 'vfe'}
win_source_folders = {'source', 'platform', 'windows', 'vfe'}
if sys.platform in {'linux'}:
    source_folders = unix_source_folders

if sys.platform[:3] == 'win':
    source_folders = win_source_folders
root_dir = os.getcwd()
root = root_dir.split('/')[-1]

prefix='POVRAY'

for folder in source_folders:
    source_key = folder.upper()
    source_key = prefix + '_' + source_key
    source_dir1 = os.path.join(root_dir,folder)
    value = source_dir1.split('/')
    plus = False
    source_value = ''
    for v in value:
        if v == root:
            plus = True
            continue
        if plus:
            source_value += v
            plus = False
    sources[source_key] = source_value
    src1 = os.listdir(source_dir1)
    for ob in src1:
        source_dir2 = os.path.join(source_dir1,ob)
        source_key1 = source_key
        if os.path.isdir(source_dir2):
            src2 = os.listdir(source_dir2)
            isCPP = False
            for ob1 in src2:
                if ob1.endswith('.cpp'):
                    isCPP = True
                    break
            if isCPP:
                source_key1 += ('_' + ob.upper())
                source_value1 = source_value
                source_value1 += ('/' + ob)
                sources[source_key1] = source_value1
                for ob1 in src2:
                    source_dir3 = os.path.join(source_dir2,ob1)
                    source_key2 = source_key1
                    if os.path.isdir(source_dir3):
                        src3 = os.listdir(source_dir3)
                        isCPP1 = False
                        for ob2 in src3:
                            if ob2.endswith('.cpp'):
                                isCPP1 = True
                                break
                        if isCPP1:
                            source_key2 += ('_' + ob1.upper())
                            source_value2 = source_value1
                            source_value2 += ('/' + ob1)
                            sources[source_key2] = source_value2
                        else:
                            continue
            else:
                continue

for i,k in enumerate(sources):
    cmakelist.write('set(%s    %s)\n'%(k,sources[k]))
cmakelist.write('\n\n')

for i,k in enumerate(sources):
    aux = k.replace('_','')
    cmakelist.write('aux_source_directory( ${%s}    %s)\n'%(k,aux))
cmakelist.write('\n\n')

for pack in cmake_packages:
    cmakelist.write('find_package(%s REQUIRED)\n'%pack)
cmakelist.write('\n\n')

for i,mod in enumerate(pkg_modules):
    cmake_name = mod.upper()
    cmakelist.write('pkg_search_module(%s REQUIRED %s)\n'%(cmake_names[i],mod))
cmakelist.write('\n\n')

cmakelist.write('include_directories(\n')
for i,k in enumerate(sources):
    aux = k.split('_')
    if len(aux) == 2:
        cmakelist.write('       ${%s}\n'%(k))
for lib in external_library:
    cmakelist.write('       ${%s_INCLUDE_DIRS}\n'%lib)
cmakelist.write(')\n')
cmakelist.write('\n\n')

cmakelist.write('add_executable(\n')
cmakelist.write('       ${PROJECT_NAME}\n')
for i,k in enumerate(sources):
    aux = k.replace('_','')
    cmakelist.write('       ${%s}\n'%(aux))
cmakelist.write(')\n')
cmakelist.write('\n\n')

cmakelist.write('target_link_libraries(\n')
cmakelist.write('       ${PROJECT_NAME}\n')

for lib in external_library:
    cmakelist.write('       ${%s_LIBRARIES}\n'%lib)
cmakelist.write('       -lz -lm boost_thread boost_system\n')
cmakelist.write(')\n')

cmakelist.close()

Post a reply to this message

Am 22.10.2016 um 12:42 schrieb LanuHum:
> For example, the structure is different from the master and hgpovray.
> Now I understand why stupid written configuration files gnumake.
> CMakeListsGenerator.py

So instead of an Automake script we'd get a Python script?

I'm not sure if this is really a win -- most notably since Automake does
a lot more than just determine what files to compile and what libraries
to link, such as detecting whether particular semi-standard include
files, data types or functions are available (defining all those
HAVE_SOMETHING macros you find scattered throughout the POV-Ray source
code).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 22.10.2016 um 12:42 schrieb LanuHum:
> > For example, the structure is different from the master and hgpovray.
> > Now I understand why stupid written configuration files gnumake.
> > CMakeListsGenerator.py
>
> So instead of an Automake script we'd get a Python script?
>
> I'm not sure if this is really a win -- most notably since Automake does
> a lot more than just determine what files to compile and what libraries
> to link, such as detecting whether particular semi-standard include
> files, data types or functions are available (defining all those
> HAVE_SOMETHING macros you find scattered throughout the POV-Ray source
> code).


I do not reinvent the wheel. I just do not know Automake, but need to build the
program. I do not know where I have to write the changes to be included in your
project my files. I found a solution to the primitive, but it works.

My posts on this thread are just an idea.
Someone might want to develop it.
The source code of the blender always had several options for building:
cmake, make and scons.
Scons uses python.


:)

Post a reply to this message

"LanuHum" <Lan### [at] yandexru> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 22.10.2016 um 12:42 schrieb LanuHum:
> > > For example, the structure is different from the master and hgpovray.
> > > Now I understand why stupid written configuration files gnumake.
> > > CMakeListsGenerator.py
> >
> > So instead of an Automake script we'd get a Python script?
> >
> > I'm not sure if this is really a win -- most notably since Automake does
> > a lot more than just determine what files to compile and what libraries
> > to link, such as detecting whether particular semi-standard include
> > files, data types or functions are available (defining all those
> > HAVE_SOMETHING macros you find scattered throughout the POV-Ray source
> > code).
>
>
> I do not reinvent the wheel. I just do not know Automake, but need to build the
> program. I do not know where I have to write the changes to be included in your
> project my files. I found a solution to the primitive, but it works.
>
> My posts on this thread are just an idea.
> Someone might want to develop it.
> The source code of the blender always had several options for building:
> cmake, make and scons.
> Scons uses python.
>
>
> :)


The first CMake repository provided by ideasman42 has been removed :-( I asked
if he had kept an archive and no he didn't ... would any compulsive downloader
have kept a version somwhere? I tried the Internet Archive to no success as
well.

Post a reply to this message

Am 11.06.20 um 16:54 schrieb Mr:
> "LanuHum" <Lan### [at] yandexru> wrote:
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 22.10.2016 um 12:42 schrieb LanuHum:
>>>> For example, the structure is different from the master and hgpovray.
>>>> Now I understand why stupid written configuration files gnumake.
>>>> CMakeListsGenerator.py
>>>
>>> So instead of an Automake script we'd get a Python script?
>>>
>>> I'm not sure if this is really a win -- most notably since Automake does
>>> a lot more than just determine what files to compile and what libraries
>>> to link, such as detecting whether particular semi-standard include
>>> files, data types or functions are available (defining all those
>>> HAVE_SOMETHING macros you find scattered throughout the POV-Ray source
>>> code).
>>
>>
>> I do not reinvent the wheel. I just do not know Automake, but need to build the
>> program. I do not know where I have to write the changes to be included in your
>> project my files. I found a solution to the primitive, but it works.
>>
>> My posts on this thread are just an idea.
>> Someone might want to develop it.
>> The source code of the blender always had several options for building:
>> cmake, make and scons.
>> Scons uses python.
>>
>>
>> :)
> 
> 
> The first CMake repository provided by ideasman42 has been removed :-( I asked
> if he had kept an archive and no he didn't ... would any compulsive downloader
> have kept a version somwhere? I tried the Internet Archive to no success as
> well.
> 
> 
> 
> 
Hello !
Look at
<5ee393f7$1@news.povray.org>

povray.binaries.programming

regards
Thomas

Post a reply to this message