SFML not honoring CMAKE_INSTALL_PREFIX

[fxcoudert]

SFML not honoring CMAKE_INSTALL_PREFIX

The cmake convention is that make install will install things in subdirectories of CMAKE_INSTALL_PREFIX. Often you can override this, but the default values of other directories and prefixes are based on CMAKE_INSTALL_PREFIX, not hardcoded.

I see from #1496 that SFML appears to have a different choice, and I've read the documentation at https://www.sfml-dev.org/tutorials/2.5/compile-with-cmake.php saying that on macOS, some paths are hardcoded. This is really contrary to what CMAKE_INSTALL_PREFIX means, and I would like you to reconsider and fix it.

Where I'm talking from: I'm a Homebrew maintainer, and we package _a lot_ of different software. And having paths not honoring CMAKE_INSTALL_PREFIX makes the job harder. Currently we can't update SFML, because our build is stuck due to this issue: https://github.com/Homebrew/homebrew-core/pull/37187 I can fix it today by adding SFML_DEPENDENCIES_INSTALL_PREFIX and SFML_MISC_INSTALL_PREFIX, but it might then be broken again if the future, when you guys create a new SFML_FOOBAR_INSTALL_PREFIX.

Please, pretty please, don't hardcode paths outside CMAKE_INSTALL_PREFIX.

[eliasdaler]

I totally agree, CMAKE_INSTALL_PREFIX should totally be respected.

@Ceylo @JonnyPtn - can you please take a look?

[JonnyPtn]

Yeah completely agree

[gracicot]

Thank you for bringning up that issue again. My package manager don't support SFML on mac for this reason. At the time, my issue was simply closed as it was the intended behaviour. I'm happy to see some change in that area. Installing a package should not change anything outside the install prefix.

[eXpl0it3r]

Sounds reasonable to follow the defacto standard. Anyone willing to write a fix for this?

[JonnyPtn]

1576 should address it I think?

[eXpl0it3r]

With #1576 merged, could you recheck whether this still needs adjusting, @gracicot & @fxcoudert?

[gracicot]

@eXpl0it3r Thank you! It indeed fixes the problem I had.