Page MenuHome

Fix deps directory in GNUmakefile
ClosedPublic

Authored by Luca Rood (LucaRood) on Sat, Feb 9, 12:35 AM.

Details

Summary

DEPS_INSTALL_DIR is using uname -p which returns "unknown" in many distros or is even unavailable due to -p not being a POSIX standard argument. This causes a mismatch between the path generated in the makefile and the path in CMake, which is using CMAKE_SYSTEM_PROCESSOR, and thus resulting in the dependencies not being found.

This patch changes the cpu detection to use uname -m instead, which is a POSIX standard, and gives more reliable results in most cases, and also matches what CMake does with CMAKE_SYSTEM_PROCESSOR in most cases. As far as I can tell, this should virtually always give identical results to CMake on Linux. The only issue I can see is with OSX (or BSD, but it is not officially supported, right?), which has some special handling in in the CMake code, but I'm not familiar with the build process on OSX at all, and I don't have an OSX machine available, so it would be best if someone else would chime in here.

As far as I can see, short of replicating the CMake code in the GNUmakefile, this is as close as it gets to matching the two. Or should we perhaps use the same uname command in both the makefile and in the CMake configs, instead of CMAKE_SYSTEM_PROCESSOR?

For reference, I consulted the CMake implementation here: https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/CMakeDetermineSystem.cmake

Any thoughts on this?

Diff Detail

Repository
rB Blender

Event Timeline

Luca Rood (LucaRood) edited the summary of this revision. (Show Details)
This revision is now accepted and ready to land.Sat, Feb 9, 1:27 AM

Checked CMake's logic and its fairly involved using -p or -m depending on the platform,
we can avoid this since we dont support some of these obscure systems.

OpenBSD uses uname -s but from reading their man page they support -m too, so LGTM.