Am 06.08.2021 um 21:04 schrieb Warren:

> I think you should consider the 'CMake' tool. It is used in more and more
> projects, and with its scripting language allows the user to choose the building
> process, that can be (not exhaustive):
> -Compile the project with a Makefile under Windows or Linux
> -Compile the project under Windows with a Visual Studio Solution.
> -Other compilations solutions...
> -Setup some files (else than the generated binaries) in the standard directories
> of differents OSes, /usr/local/share or C:\Program Files\'project dir' for
> example.
> 
> All you need to do is to write one or several files named 'CMakeLists.txt' and
> use the CMake script language. I use CMake in my games projects, it is present
> in many Unix standard repositories and is of course available for Windows and is
> free.
> 
> One good point is that you must write only one 'CMakeLists.txt' file per
> binary/project even if you target several OSes.

The not so good point is that we must write one `CMakeLists.txt`.

Since we're primarily developing on Windows using Visual Studio 
(specifically VS 2015), that's not a thing that is directly supported by 
our primary IDE.

Most notably, _each and every_ change to the set of files that make up 
the POV-Ray source code (be it the addition of a new file, the removal 
of an obsolete one, or the renaming or moving of a file) since the 
release of POV-Ray v3.7.0.0 was done from the seat of a Visual Studio 
jockey.

And as things stand at the moment, VS is the _only_ place we need to 
maintain _any_ such lists of files that need compiling: The current 
Autotools-based process generates its own list on the fly using a fully 
automatic system. (Unless you get a *NIX-specific source tarball, in 
which case that step has already happened).

 From what I've seen of CMake on the other hand, it seems to be 
incapable(*) of such stunts, which I find extremely disappointing for a 
supposedly modern build system. To have a directory sub-tree entirely 
devoted to the software's source code, such that every file in there is 
to be compiled, seems such a trivially common use case to me that I find 
it ridiculous that a modern build system doesn't address it.

(*While there are workarounds that promise to accomplish something like 
that, the CMake authors themselves explicitly state that those 
workarounds don't actually... work.)


Also, I may be misunderstanding things, but I presume CMake does not 
natively cater to a project that has, in some sense, completely 
different applications for different target platforms, which "only" 
share a common core.


All in all, I don't see CMake solving _any_ problem we might currently 
have, while at the same time it would be moving any necessary day-to-day 
maintenance to a place where it is less accessible to us.

Things might change if we add an official third "incarnation" (as I like 
to call them) besides POV-Ray for Windows and POV-Ray for Unix, such as 
a Qt-based portable GUI version of POV-Ray, a Mac-specific one, or 
whatever. But until then, switching over to CMake seems to be more pain 
than gain.


At any rate, CMake won't do anything to help with the original topic of 
this thread, namely XP compatibility.

Post a reply to this message