clipka <ano### [at] anonymousorg> wrote:
> Am 19.07.2021 um 05:22 schrieb HKarsten:

[...]
> We prefer targeting multiple build tools, to increase support.
[...]

Hello,
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.

Post a reply to this message

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

clipka <ano### [at] anonymousorg> wrote:
> Am 06.08.2021 um 21:04 schrieb Warren:
>

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

You can mark out parts in a 'CMakeLists.txt' file like for example:

if( UNIX )
//Do these things only for Unix OSes
endif( UNIX )

if( WIN32 )
//Only for Windows OSes
endif( WIN32 )

And you also can make sub project like I do for the games I'm currently
developping like in this tree example: (directory based interpretation)

CMakeLists.txt in main project directory
|
|--'editor' sub directory that contains also a 'CMakeLists.txt' file that
generates an executable based partly on some others static libraries below, to
edit levels for the game
|--'inGame' sub directory that contains a 'CMakeLists.txt' that will build a
static library which is the game core
|--sdl2_wrapper : another static library that wraps the well known SDL2 library
so that it becomes RAII / RFID compliant ( C++ )
|--'game' generates the game excutable based on other libraries

That said I agree with you when you say CMake for now, can't generate a build
process based on a directory that may contains all the sources. But I make up
for that with a couples of commands in Ubuntu in a script shell:

#!/bin/bash
#List the sources and headers of 'inGame' directory
#
find ../sources/inGame -type f -name "*.h" > lists/inGameHeaders.txt
find ../sources/inGame -type f -name "*.cpp" > lists/inGameSources.txt
#
sed 's#../sources/inGame/#\t\t#g' -i lists/inGame*.txt

The last sed command adds two tabulation chars ('\t') so that when I paste the
txt file content , I have a suitable indentation.
And as concrete example here is a simple CMakeLists.txt :

cmake_minimum_required(VERSION 3.8)

project("game_${SQUARE_SIZE}" LANGUAGES CXX)

if(UNIX)
 include(GNUInstallDirs)
endif(UNIX)

set(HEADERS
  sources/generic/loadings/makeTextTextures.h
  sources/levels/contexts/demoLevel.h
  #This is a comment
  #Other files there
)

set(SOURCES
  sources/generic/loadings/makeTextTextures.cpp
  sources/levels/contexts/level.cpp
  #This is a comment
  #Other files there
)

add_executable( ${PROJECT_NAME}
    WIN32
    ${SOURCES}
    ${HEADERS}
    ${INC_DIRS}
)

target_include_directories(${PROJECT_NAME}
        PUBLIC ${SDL2_INCLUDE_DIRS}
        PUBLIC ${SDL2_IMAGE_INCLUDE_DIRS}
        PUBLIC ${SDL2_TTF_INCLUDE_DIRS}
        PUBLIC ${SDL2_MIXER_INCLUDE_DIRS}
        PUBLIC sources
        PUBLIC ../commonFiles/sources
        PUBLIC ../generic/sources
        PUBLIC ../inGame/sources
)

target_link_libraries( ${PROJECT_NAME}
      ${SDL2_LIBRARIES}
      ${SDL2_IMAGE_LIBRARIES}
      ${SDL2_TTF_LIBRARIES}
      ${SDL2_MIXER_LIBRARIES}
      "mercenaries_common_${SQUARE_SIZE}"
      "mercenaries_generic_${SQUARE_SIZE}"
      "mercenaries_inGame_${SQUARE_SIZE}"
)

set_target_properties( ${PROJECT_NAME}
      PROPERTIES
      CXX_STANDARD 20
      CXX_STANDARD_REQUIRED YES
      CXX_EXTENSIONS ON
      LINKER_LANGUAGE CXX
)

if( UNIX )
 math(EXPR SCREENWIDTH "${SQUARE_SIZE} * 20" OUTPUT_FORMAT DECIMAL )
 install(TARGETS ${PROJECT_NAME}
  RUNTIME DESTINATION
"/media/antoine/projetsLinux/final/MercenariesProject/Mercenaries${SCREENWIDTH}"
 )
endif(UNIX)

//-----------------End of CMakeLists.txt file
If you wonder what '${SQUARE_SIZE}' stands for, this is the logical size of a
tile in my game. In fact I use a combination of bash script files and povray to
make all textures in my game according to a given size of Tiles textures (the
size is passed to every shell scripts that compute the final size of the povray
image size that renders). Only one script to run and then some hours later, all
the textures I want are created. All I have to do then is to compile the
binaries with the same tile size that I give while running 'cmake' in command
line later.

Post a reply to this message