MegaGlest / megaglest-source

MegaGlest real-time strategy game engine (cross-platform, 3-d)
http://megaglest.org/
348 stars 89 forks source link

Look for glest.ini in ${CMAKE_INSTALL_PREFIX}/share/megaglest #167

Closed arunisaac closed 6 years ago

arunisaac commented 7 years ago

I am packaging megaglest 3.13.0 for GNU Guix SD. megaglest looks for glest.ini in standard GNU/Linux paths such as /usr/share/megaglest, /usr/share/games/megaglest, etc. However, Guix uses a non-standard install prefix, and therefore megaglest is unable to find glest.ini unless the --ini-path is explicitly passed to the megaglest command line.

If megaglest were to look for glest.ini in ${CMAKE_INSTALL_PREFIX}/share/megaglest, this problem would be solved. This also makes sense because the megaglest installation step, by default, puts glest.ini in ${CMAKE_INSTALL_PREFIX}/share/megaglest.

For the immediate problem of Guix packaging, I am working around by patching source/glest_game/global/config.cpp before building.

Thanks.

filux commented 7 years ago

Basically all should work as you need unless you found something new, not reported yet.

arunisaac commented 7 years ago

What was the whole cmake (with parameters if were used) command used by you to build MG?

cmake -DCMAKE_INSTALL_PREFIX=/gnu/store/f0ahwjn24s7sk75ibr4v9bbvqnkvj0k9-megaglest-3.13.0 -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE -DCMAKE_INSTALL_RPATH=/gnu/store/f0ahwjn24s7sk75ibr4v9bbvqnkvj0k9-megaglest-3.13.0/lib -DCMAKE_VERBOSE_MAKEFILE=ON -DCUSTOM_DATA_INSTALL_PATH=/gnu/store/ygcqfm3jdn77lqwsyvgd4f4azcd7a94m-megaglest-data-3.13.0/share/megaglest -DBUILD_MEGAGLEST_TESTS=ON

Can you show the output produced during cmake run (especially in the line containing "*NOTE: Custom Data Install Path is")?

-- Performing Test HAS_GCC_BACKTRACE -- Performing Test HAS_GCC_BACKTRACE - Success -- Found GCC backtrace lib, will support backtraces -- Found Git: /home/arun/.guix-profile/bin/git (found version "2.11.0") -- *NOTE: Custom Data Install Path is [/gnu/store/ygcqfm3jdn77lqwsyvgd4f4azcd7a94m-megaglest-data-3.13.0/share/megaglest] -- CMAKE_CXX_FLAGS_RELWITHDEBINFO: -O3 -O2 -g -DNDEBUG -g -O3 -DCUSTOM_DATA_INSTALL_PATH=/gnu/store/ygcqfm3jdn77lqwsyvgd4f4azcd7a94m-megaglest-data-3.13.0/share/megaglest -- **Found game source code. -- Found PkgConfig: /gnu/store/n5hvp8ihnxwp1v4ralxghhxgp4arq9p6-profile/bin/pkg-config (found version "0.29") -- Checking for one of the modules 'streflop-sse' -- Checking for one of the modules 'streflop' -- Search for Library STREFLOP result = libs: include dirs: -- Will try to build MegaGlest shared library

Do you want me to post the full cmake output, or will this be sufficient? The full cmake output is rather long.

Does cmake was run only once? or if not: Do previous files produced by cmake were removed first?

cmake was run only once.

What was "cmake" version used by you?

cmake version 3.6.1

filux commented 7 years ago

On the start you shouldn't give -DCUSTOM_DATA_INSTALL_PATH because it should be known automatically + I probably see 2 errors there:

  1. different prefix (/gnu/store/f0ah... vs /gnu/store/ygcq...) ... Is there a reason to keep the data at different prefix?,
  2. the path there is not ended as a directory (share/megaglest vs share/megaglest/). I am not sure it will solve the situation but is a chance for this.
arunisaac commented 7 years ago

different prefix (/gnu/store/f0ah... vs /gnu/store/ygcq...) ... Is there a reason to keep the data at different prefix?,

I'm packaging megaglest and megaglest-data as two separate packages, with megaglest-data being a dependency of megaglest. In Guix, each package has its own installation prefix. This is to allow coexistence of different versions of the same package, different users having different packages installed, etc. So, yes, megaglest and megaglest-data need to have different installation prefixes.

On the start you shouldn't give -DCUSTOM_DATA_INSTALL_PATH because it should be known automatically

Yes, I noticed that CUSTOM_DATA_INSTALL_PATH is automatically set to ${CMAKE_INSTALL_PREFIX}/${MEGAGLEST_DATA_INSTALL_PATH}. However, this assumes that megaglest and megaglest-data are installed in the same installation prefix. If I only explicitly set MEGAGLEST_DATA_INSTALL_PATH, I won't be able to account for megaglest and megaglest-data having two different installation prefixes.

the path there is not ended as a directory (share/megaglest vs share/megaglest/). I am not sure it will solve the situation but is a chance for this.

No, this doesn't help.

filux commented 7 years ago

Ok, we probably know enough about the problem now to be able to do something with it.