Installing cpu-features.h is not needed and can break builds because Ogre depends on relative paths for installing, and cpu-features.h is added as an absolute path.

#1 Merged at 949be1a
Repository
dark_sylinc
Branch
v2.1-gles3-android
Author
  1. Simon Hyll
Reviewers
Description

Installing cpu-features.h is not needed and can break builds because Ogre depends on relative paths for installing, and cpu-features.h is added as an absolute path.

Comments (2)

  1. Simon Hyll author

    An example of a build issue is when I build using Gradle on Windows: The file that CMake attempts to install to becomes something similar to "C:\Project\Libs\Android\x86_64\include\Ogre\C:\Android-SDK\ndk-bundle..\cpu-features.h". Personally I would recommend a complete overhaul of how Ogre handles its source files and installing those files so they always rely on absolute paths for input using ${CMAKE_SOURCE_DIR}/Input/File, then e.g. replacing CMAKE_SOURCE_DIR with ${CMAKE_BINARY_DIR}/Input/File. That however is a much larger undertaking and would require some sort of consensus before I begin working on it.

  2. Matias Goldberg repo owner

    "Personally I would recommend a complete overhaul of how Ogre handles its source files and installing"

    Oh I fully agree on that. I've been wanting to fix the INSTALL script (right now my recomendation is to not use install) but I haven't got the time; and our CMake scripts have spider webs from their old age. We were one of the first adopters of CMake, back when it had a lot of bugs our scripts workaround, or we implemented macros to perform tasks that are now offered out of the box by CMake. Like you said, that is a big undertaking.

    Right now the most obvious problem (on all platforms) is that the INSTALL folder structure does not match out-of-source builds at all. So a user that wants to switch from "prebuilt SDKs" to "out of source builds" (or viceversa) has to make a significant work to make the move, and would have a hard time if he wants to support both at the same time.

    Another problem is that Windows' MSVC and Apple's XCode can do both Debug & Release at the same time, but Linux can only do one at the same time... which is easily workaroundable by establishing strong conventions on having Linux build under "build/Debug" instead of building inside the "build" folder (have a good time guessing whether it's Debug, Release, RelWithDebInfo, etc). Right now it's the wild west in this regard.

    Another problem is with our dependencies (ogredeps) where each platform is inconsistent. For example in Windows and Linux zlib is compiled as "zlib", but on macOS it's compiled as "z".

    These inconsistencies makes things hard, and wants me pull out the little hair I have left from my head.

    I don't think I prefer absolute paths; I rather prefer relative paths with a few exceptions, but although we may disagree on some of the details, I very much agree a complete overhaul is needed.