update: unlock native Linux build for CMake and CPU backend only

[incertum]

Unlock native Linux build for CMake and CPU backend only.

---

Related to https://github.com/ml-explore/mlx-swift/issues/258.

This PR follows the principle of making the minimal initial changes necessary to unlock native Linux builds with CMake —nothing more.

The CUDA backend for native Linux builds in CMake is something to explore afterward, knowing there are already things moving (see https://github.com/ml-explore/mlx-swift/issues/258). CC @davidkoski and @zamderax

@joannis for follow (SSWG)

[davidkoski]

Testing failed:
        'asDataCopy' is inaccessible due to 'private' protection level
        Testing cancelled because the build failed.

this is from the asMTLBuffer -- I think we can just make asDataCopy to be internal

[davidkoski]

I wonder if it is worth adding a circleci config to do the linux build?

[incertum]

I wonder if it is worth adding a circleci config to do the linux build?

Let's do GitHub workflows -- let me check on this.

We should have one YUM based and one DEB based distro to get started.

[davidkoski]

I wonder if it is worth adding a circleci config to do the linux build?

Let's do GitHub workflows -- let me check on this.

We should have one YUM based and one DEB based distro to get started.

True, I guess I should get that set up. Right now CI tests:

• swift-format (this isn't needed on the linux side as the macOS one will check all files)
• compile
• run unit tests

Compile is probably the most important as we could very easily break the linux build. The unit test one has a hook setDefaultDevice() that is actually still using the cpu. Huh. Well, anyway it has a hook that will be useful for the linux build.

[incertum]

Quick note: New plan see https://github.com/ml-explore/mlx-swift/issues/294 meaning let's wait before merging this PR, but it should be considered complete in scope.