[MLX] Updated to 0.21.0 #9898
[MLX] Updated to 0.21.0 #9898
Conversation
stemann
force-pushed
the
feature/mlx_0.21
branch
2 times, most recently
from
da76fdd to
1b15396
Compare
|
When building MLX C (#9809), it was necessary to also have MacOSX14.0.sdk present in I am wondering whether the produced cmake config should be patched... but not sure what would be right. The pre-built $ diff -ru aarch64/share x86_64/share
diff -ru aarch64/share/cmake/MLX/MLXConfig.cmake x86_64/share/cmake/MLX/MLXConfig.cmake
--- aarch64/share/cmake/MLX/MLXConfig.cmake 1970-01-01 01:00:00
+++ x86_64/share/cmake/MLX/MLXConfig.cmake 1970-01-01 01:00:00
@@ -39,14 +39,14 @@
set(MLX_CXX_FLAGS ${MLX_CXX_FLAGS} -DACCELERATE_NEW_LAPACK)
endif()
-if (ON)
- set(MLX_BUILD_METAL ON)
+if (OFF)
+ set(MLX_BUILD_METAL OFF)
set(MLX_CXX_FLAGS ${MLX_CXX_FLAGS} -D_METAL_)
set(MLX_INCLUDE_DIRS
"${MLX_INCLUDE_DIRS};"
${PACKAGE_PREFIX_DIR}/include/metal_cpp
)
- if(300 GREATER_EQUAL 310)
+ if( GREATER_EQUAL 310)
set(MLX_INCLUDE_DIRS
"${MLX_INCLUDE_DIRS};"
${PACKAGE_PREFIX_DIR}/include/mlx/backend/metal/kernels/metal_3_1)
diff -ru aarch64/share/cmake/MLX/MLXTargets.cmake x86_64/share/cmake/MLX/MLXTargets.cmake
--- aarch64/share/cmake/MLX/MLXTargets.cmake 1970-01-01 01:00:00
+++ x86_64/share/cmake/MLX/MLXTargets.cmake 1970-01-01 01:00:00
@@ -1,13 +1,13 @@
# Generated by CMake
if("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" LESS 2.8)
- message(FATAL_ERROR "CMake >= 2.8.12 required")
+ message(FATAL_ERROR "CMake >= 2.8.0 required")
endif()
if(CMAKE_VERSION VERSION_LESS "2.8.12")
message(FATAL_ERROR "CMake >= 2.8.12 required")
endif()
cmake_policy(PUSH)
-cmake_policy(VERSION 2.8.12...3.29)
+cmake_policy(VERSION 2.8.12...3.28)
#----------------------------------------------------------------
# Generated CMake target import file.
#----------------------------------------------------------------
@@ -59,8 +59,8 @@
add_library(mlx SHARED IMPORTED)
set_target_properties(mlx PROPERTIES
- INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/metal_cpp;${_IMPORT_PREFIX}/include;${_IMPORT_PREFIX}/include"
- INTERFACE_LINK_LIBRARIES "-framework Metal;-framework Foundation;-framework QuartzCore;/Applications/Xcode-15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/System/Library/Frameworks/Accelerate.framework"
+ INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include;${_IMPORT_PREFIX}/include"
+ INTERFACE_LINK_LIBRARIES "/workspace/srcdir/MacOSX14.0.sdk/System/Library/Frameworks/Accelerate.framework"
)
# Load information for each installed configuration. |
stemann
force-pushed
the
feature/mlx_0.21
branch
from
1b15396 to
096edf5
Compare
M/MLX/build_tarballs.jl
Outdated
| git remote add upstream https://github.com/ml-explore/mlx.git | ||
| git fetch upstream | ||
| git checkout -B patches | ||
| git cherry-pick 698e63a608bbee43bd70a76602dbf2bd6636877f # CMake: Build with dlfcn-win32 to have dlopen etc. on win32 (#1628) |
There was a problem hiding this comment.
I haven't seen this pattern before – using the build script to download more code. Usually the recipes put patches into a bundled/patches directory.
There was a problem hiding this comment.
Nope, it’s new :-)
It’s just that these patches were already upstreamed, so it seems cleaner to just get them from the source, but we don’t want a newer commit than v0.21 as other (possibly breaking) changes has also been merged.
There was a problem hiding this comment.
Why not adding a patch (which are also cached, contrary to what you're doing here)? That looks much cleaner than doing all this needless dance.
There was a problem hiding this comment.
I can re-add the patches, though they will be gone by v0.21.1 (just released).
… they should be in this branch already - but not at the latest commit.
I would still like to build v0.21.0 as this is the version used by MLX C v0.1.0.
There was a problem hiding this comment.
I can re-add the patches, though they will be gone by v0.21.1 (just released).
That's just normal: we backport patches all the time. Fiddling with the git repo looks more messy to me.
There was a problem hiding this comment.
I beg to differ, but I've restored the patches now :-)
|
@giordano Any thoughts on the cmake config comment: #9898 (comment) |
* Reverted "Using proper v0.21.0 - cherry-picking merged upstream patches" * Reverted "Using commit without need for patches" * Removed cmake-win32-io patch from cmake-w64-mingw32 patch * Made upstreamed patches unconditional
Summary: