On 3/20/20 2:35 PM, Warren wrote:
> If you are ever looking for a polyvalent build system for the POVRay sources (as
> much for Windows than Linux than other platforms), you should take a look at
> "CMake" (www.cmake.org). Personnally , I use it for my projects and don't regret
> it. All you have to do is writing a file:
> CMakeLists.txt (with the cmake scripting language.)
> Then the user who has downloaded (for example) the POVRay source code can choose
> the compiler, the project type (that can be 'Codelite project'/'Visual studio
> project'/'Unix Makefile'/'MinGW makefile' or many else).
> 
> Cmake is well known nowadays. ;-)
> 

Yes, I'm aware of cmake having looked at many build systems while 
digging into a particular build issue back in 2017. I think it's 
strengths come to good support for IDEs and common usage which increased 
especially while the autotools package support was unstable and 
fractured in the 2000s. It's weakness is it needs to be installed to be 
used(1); that it created it's own scripting language(2) which you have 
to learn; and that like autotools you can get into version issues(2).

At a high level I'm headed in the opposite direction to cmake and 
'autotools' support everything model with my cut down *nix only version 
of POV-Ray. I'm looking to support much less in the way of OSs and 
architectures to make my hobby like simpler.

Bill P.

(1) Not how POV-Ray is being provided today, but the autotools approach 
is the developer creates the configure script and only that configure 
script is packaged for a users/administrators to run ahead of a 
compile/install. Nothing extra needs to be installed on the system 
beyond having a compliant c++ compiler which is kinda cool.

(2) One build system I liked over both cmake and autotools -  partly due 
me already knowing tcl - was a tool called autosetup. It requires tcl to 
run, but the package includes a tiny implementation of tcl called jim 
tcl which it will compile on the fly - given an ansi-c compiler on the 
system - if need be. This build system becomes part of a project's code 
so no versioning issues. It's basically a couple guys though - and aimed 
too at just *nix and mostly c/c++. In theory at least - gnu autoconf / 
gnu make there is surer, if not at any given time better - support given 
it's a GNU tool needed for linux and gnu core tool compiles.

Aside (2a): Seeing autosetup I wondered if the cmake guys could have 
saved themselves some implementation effort by starting with an 
extension language like tcl, lua or maybe scheme/guile. GNU make itself 
now supports guile written functions - and dll extensions 'experimentally.'

Post a reply to this message