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
When using mac ports GL/gl.h ends up outside the cmake search paths for
libraries and includes. By adding them to mk/macos/CMakeLists.txt they are now
available and make it possible to build g3d_viewer along with the rest of
megaglest. To make this work properly I had to move the inclusion of
mk/macos/CMakeLists.txt further up the master CMakeLists.txt so merged both IF
APPLE tests in to one.
This has built successfully through xcode and gnumake.
I noticed that mk/macos/CMakeLists.txt has special code for extracting the
megaglest version , but its already done in CMakeLists.txt. This removes the
duplicate detection and changes the users of MEGAGLEST_VERSION to
MG_VERSION_H_CONTENTS.
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.
SoftCoder