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.
(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