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