Within 5 lines CUSTOM_DATA_INSTALL_PATH is defined twice resulting in lots of
compiler warnings; eg
[ 11%] Building CXX object source/shared_lib/sources/streflop/CMakeFiles/streflop.dir/libm/flt-32/s_atanf.cpp.o
In file included from <built-in>:175:
<command line>:7:9: warning: 'CUSTOM_DATA_INSTALL_PATH' macro redefined
^
<command line>:2:9: note: previous definition is here
^
This removes the second definition.
Conflicts:
CMakeLists.txt
Without this change building the Release version results in an error (which
claims to be a warning) due to using -s which is obsolete.
This removes -s when building through xcode - gnumake and other platforms are
(presumably) unaffected.
Following the work I did on GH ' Remove special casing on GIT_VERSION_CMD #33 '
I've done more experiements and test rebuilds. I've found that the test should
actually be to find out if we are working with Xcode specifically as using the
gnu build chain is working correctly with the code in the 'else' clause - the
codepath i tested before doing my original changes - but doesn't work using the
special 'apple' version.
This change should mean both methods of building work correctly.
When trying to build a dmg package on an apple system the values set in
mk/macos/CMakeLists.txt are masked by those coded in the main CMakeLists file.
This change means the values are only set if they haven't been already (eg by
using the apple CMakeLists).
I feel it would probably be better to move this lot ot mk/linux/CMakeLists and
then conditionally import the correct file - I'm happy to redo the change that
way if there is agreement on that.
Had a chat with softcoder who explained what was going on. We should now be
almost identical to the original but the compiler specific test has been
removed.
The special codepath for CUSTOM_DATA_INSTALL_PATH on OSX means the path is
generated multiple backslashes which cause problems later on in the compile.
Having the same codepath as everything else appears to resolve this problem.
The CUSTOM_DATA_INSTALL_PATH constant is checked at different
places in the code but was not actually passed to the compiler.
This resulted in searching the data files in /usr/games instead
of /usr/share/games/megaglest (in Ubuntu and Debian).
This commit also fixes setting the variable. It is still wrong
for Apple I think. But I can not test it.
- fontconfig not working
- new cmake option to control inclusion of libvlc
- new commandline option to force where to look for fonts: --font-path=x
- removal of libluajit from cmake
BUILD_MEGAGLEST_MODEL_IMPORT_EXPORT_TOOLS
BUILD_MEGAGLEST_MODEL_VIEWER
BUILD_MEGAGLEST_MAP_EDITOR
BUILD_MEGAGLEST_CONFIGURATOR
BUILD_MEGAGLEST
By default these are all enabled (On). Turn turn off a module run cmake with the option turned off:
-DBUILD_MEGAGLEST_CONFIGURATOR=OFF
- missing glest.ini during make install (this file is handled by the data install)
- properly handles destdir for all installed files
- customizable paths for all installation destinations (the following can now be set):
MEGAGLEST_BIN_INSTALL_PATH - "bin/" - "The installation path for binaries (this is appended to the CMAKE_INSTALL_PREFIX)")
MEGAGLEST_DATA_INSTALL_PATH - "share/megaglest/" - "The installation path for data files (this is appended to the CMAKE_INSTALL_PREFIX)")
MEGAGLEST_DESKTOP_INSTALL_PATH - "share/applications/" - "The installation path for desktop files (this is appended to the CMAKE_INSTALL_PREFIX)")
MEGAGLEST_ICON_INSTALL_PATH - "share/pixmaps/" - "The installation path for icon files (this is appended to the CMAKE_INSTALL_PREFIX)")
CUSTOM_DATA_INSTALL_PATH - "'\\\"${CMAKE_INSTALL_PREFIX}/${MEGAGLEST_DATA_INSTALL_PATH}\\\"'" - "The FULL installation path for data files (this is build automatically by combining CMAKE_INSTALL_PREFIX and MEGAGLEST_DATA_INSTALL_PATH)")
- Fixed startup scripts for tools (remove bin folder)
- Fixed source and data tarball scripts to include required files (missed the proper main ini files)
- Debian can now easily package up megaglest and build deb files
Karl Goetz