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