Running CLP from Xcode for macOS

[theogscott]

Revised Text

My goal is to be able to pull the source code, create a build in Xcode targeting macOS (and eventually iOS).

I am aware that binary/library distributions exist for macOS, and I am not trying to replace them. However, contributing, experimenting, or investigating becomes difficult when you only have a Mac—especially if you stopped using Windows PCs and Visual Studio a long time ago. Until recently I worked with the LP/MIP algorithms on IBM OSL on both PC (Visual Studio) and an IBM RS/6000 machine, mainly via Fortran 90 and XLC together with IBM ESSL in commercial and academic environments. That was many years ago.

My first goal was to fork all the repositories (CoinUtils, OSI, Clp, Test Data – NetLib, Sample), re‑compile them without having to run any shell commands or use Coinbrew, and keep the setup as similar as possible to the Visual Studio one, with minimal changes. I followed the MS Visual Studio structure to retain familiarity and so that I could learn how all the libraries fit together (using Windows 11 ARM and VS 2022 ARM in a VM). I converted each library into a Swift Package (SPM), preserving the original naming conventions—libClp, libCoinUtils, libOsi, libOsiClp, libOsiCommonTest, osiUnitTest from Clp.sln—and placed them in an SPM branch for each repository.

The Swift Package Manager (SPM) is named after Apple’s programming language Swift, but it can also build C and C++ source code. See the documentation: https://developer.apple.com/documentation/xcode/swift-packages.

In the end I managed to get everything to build without modifying any C++ code, except for:

1. Adding configall_system_aaplxcode.h, similar to configall_system_msc.h (I’m not 100 % sure the file is complete; some macros may be missing).
2. Placing a Package.swift file at the root of each GitHub repository—SPM cannot use a Package.swift that lives in a subfolder (unlike Visual Studio, which can have project files under MSVisualStudio/{Version}/*.vcxproj). An SPM package may contain more than one library and can mix languages.
3. Adjusting the NetLib, Sample data, and miplib3 resources. I wrapped these in a package so that, when you run the unit tests, they are automatically copied to the appropriate location. To do this I moved the .mps files into a subfolder called Resources.

Clp Examples

If you have a Mac with Xcode 26 (or later), clone the repository:

https://github.com/theogscott/Clp

Open ./Xcode/Clp/Clp.xcodeproj. At the top of the project you will see the targets ClpExampleMinimum and ClpExamplesTestBarrier. Both require an .mps file as a command‑line argument. Hold the Option key, click Run from the Product menu, and a dialog will appear where you can add the path to the .mps file under Arguments Passed on Launch.

To run the unit tests:

1. Close Xcode/Clp/Clp.xcodeproj.
2. In Finder, go to the root folder of the Clp repository and double‑click Package.swift.
3. From the Product menu choose Test (or press ⌘U).

The test harness will fetch all NetLib and sample data. If everything is set up correctly you should see output similar to:

Test Case '-[XCosiUnitTest.OSITest testOSIUnit]' passed (0.373 seconds).
Test Suite 'OSITest' passed at 2026-02-22 22:30:30.318.
    Executed 1 test, with 0 failures (0 unexpected) in 0.373 (0.374) seconds
Test Suite 'XCosiUnitTest.xctest' passed at 2026-02-22 22:30:30.318.
    Executed 1 test, with 0 failures (0 unexpected) in 0.373 (0.374) seconds
Test Suite 'All tests' passed at 2026-02-22 22:30:30.319.
    Executed 1 test, with 0 failures (0 unexpected) in 0.373 (0.374) seconds
Program ended with exit code: 0

If the maintainers of Clp, Osi, or CoinUtils would like me to open a pull request, I am happy to do so and to help further. Please feel free to ask any questions or point out anything I may have missed.

---

P.S. There is a function declaration:

int mainTest(int argc, const char *argv[], int algorithm,
             ClpSimplex empty, ClpSolve solveOptionsIn,
             int switchOffValue, bool doVector);

The linker kept complaining about an undefined reference to this symbol, even though it is never called in the examples or unit‑test CLI. To silence the error I created a dummy implementation (mainTest.cpp). It appears that the function is not needed for the current build, but I left the placeholder in case future code requires it.

[pratikrath126]

Hey @theogscott, this is a really impressive piece of work! Getting CLP and its dependencies (CoinUtils, OSI) running smoothly with Swift Package Manager on macOS/Xcode is a great contribution, especially for those of us who prefer the Apple ecosystem over Windows/Visual Studio.

I particularly like how you've handled the resource files for unit tests within the SPM structure—that's often one of the trickier parts of moving older C++ projects to modern package managers.

Since you mentioned you're open to PRs, have you considered how this might work with CI/CD on GitHub Actions? It would be awesome to see these SPM builds automatically verified.

Thanks for sharing this with the community!

[theogscott]

@pratikrath126 Yes I have thought about it, if you want to configure a CI/CD pipeline that will run the units test on old and new devices which might include iOS and they different flavours of OS version, then I would suggest using Apple Xcode Cloud. That should be pretty easy, and mostly free for the COIN-OR Foundation, Inc., is a non-profit educational and scientific foundation because of Apple's Developer Program fee waiver.

[theogscott]

@pratikrath126 – You asked whether—and how—a CI/CD pipeline can be used to verify that a build is valid. I mentioned that one option is Xcode Cloud, which runs on Apple’s development infrastructure; of course there are also other CI/CD servers that can handle macOS builds.

Keep in mind that the next release of macOS will drop support for Intel‑based Macs, so you won’t be able to cross‑compile with the latest Xcode. Fortunately, SPM (Swift Package Manager) makes this more manageable because platform‑OS version compatibility is handled inside the package. Xcode automatically selects the newest package version that satisfies all constraints, including the macOS deployment target you have set (which is normally the macOS version installed on your machine).

Let me give you an example of how this works, and I am sure you are familiar with it. Below is a pull request I created:

theogscott#1

The build will fail on purpose to demonstrate how a branch can be protected. The source code compiles without error ( libClp | Analyse PR to SPM | Analyze – macOS ), but the Release/Archive build fails ( libCIp | Analyse PR to SPM | Archive – macOS ) because of a linker error.

Consequently, a pull request will not be approved nor merged until the errors are resolved for a Release build. Things become a lot more complicated when there are inter‑dependent libraries, as in this case. For example, a PR that passes on CoinUtils might break Clp; how to handle such conflicts is a policy decision that the maintainer must define.

@tkralphs – I see you’re the technical lead. How should we proceed with getting these changes into the main repository? It will probably require some planning, especially if we want to add a CI/CD pipeline for macOS (and other operating systems). I’m not sure how the current build process would accommodate that.

[tkralphs]

Unfortunately, I'm not very familiar with the tool chain you are talking about here. As a general rule, I'm hesitant to adopt anything for which the ability to maintain it in the long term is questionable. We have a CI/CD pipeline set up already that includes MacOS builds and we support MacOS installation through Conda and Homebrew. Maybe you could explain why those options are not sufficient? In general, the MacOS users of Clp/Cbc seem to have been happy with those options over an extended period of time.

My general preference is to avoid any dependance on vendor-specific, non-open-source tools, especially ones that I don't have easy access to or don't work with. I work with MacOS a little, but always use cross-platform build processes and non-Apple, open-source tools. Every time I've gotten involved with some sort of apple-specific stuff, it's been a rabbit hole.

The one exception to using vendor-specific tools is the CI we have for Visual Studio on Windows. @jhmgoossens maintains this independently and it is largely contained to a single subdirectory for the project files and a separate workflow. I would be open to having a similar setup here if I could be convinced of the need and that it would get maintained. I would probably want to introduce it in master first and only release it with new stable branch that seems to be nearing creation. Thoughts?

[theogscott]

Thank you for replying.

As I mentioned before, I am aware that binary/library distributions exist for macOS, and I am not trying to replace them. The problem for me is that those libraries target only macOS; they cannot be used on other platforms such as iOS. You might say this is a personal goal rather than something that benefits others, and I would respond that’s fine—we could stop there. In my own fork of the repository I would simply sync the master/main branch into my fork whenever needed.

What I am offering/sharing

A Visual‑Studio–like setup for Xcode – just as you have a .vcxproj (XML) file for Visual Studio, Xcode uses Package.swift. The workflow is almost identical: the same naming conventions (e.g., libClp, libCoinUtils, libOsiCommonTest, libOsi, libOsiClp, etc.) can be used, and the overall process follows the same principles.

CI/CD integration – If you already have a pipeline that builds for macOS, there is no need to create another one. Do you run the tests on CI/CD ? Do you execute them for both Intel and Apple Silicon?

What we need

We need a trusted macOS user who can evaluate whether this approach would be useful. If macOS users are satisfied with what you are providing, I do not want to upset the current codebase. However, based on @pratikrath126’s initial reaction, I suspect there may be others looking for a way to run this from Xcode.

If it helps, to see how, it would work in Xcode:

1. Clone https://github.com/theogscott/Clp
2. Open the example project Xcode/Clp/Clp.xcodeproj (.xcodeproj, is similar to .sln in VS-Studio)
3. Build it Cmd-B
4. Want to run the example: select a target, say ClpExmplesMinimum
5. Hit ALT-CMD-R, then add an MPS as the first argument, below I am using p0033.mps

6. tap Run on the right-bottom

7. What did I do ? I build Clp/examples/minimum.cpp the same source with no changes and run it.

[jhmgoossens]

Hi. I'm also not familiar with Xcode nor SPM, but of course I see the point of supporting a popular IDE (..)

About changing existing files/folders

Adjusting the NetLib, Sample data, and miplib3 resources. I wrapped these in a package so that, when you run the unit tests, they are automatically copied to the appropriate location. To do this I moved the .mps files into a subfolder called Resources.

Is it necessary to move those files? Wouldn't that move impact other build and test workflows that are already in place? Or maybe I misunderstand.

About hardcoded references

I see Xcode Package.resolved files mention URLs to your fork. Are these hardcoded references necessary? Would those work in forks?

About CI/CD

Part of the reason for the windows-msvs-ci.yml workflows is that the testing of the VS project files, so all still builds. And of course also to run the unit tests. Therefore, yes, I think it would be good to also a separate CI/CD for Xcode / SPM based builds--not just the coinbrew clang / gcc builds.

Each of the coin-or dependencies of Cbc (Clp, Cgl, CoinUtils, Osi) has (almost exactly) the same workflow files files, for maintainability. This makes updating the workflow easier when a newer runner is released (like for macos-26 recently). Is something like this achievable, so the workflow, the Xcode and SPM would be similar?

About Xcode Cloud

Since the macos-26 runner image includes Xcode, couldn't we define a github workflow that uses the SPM/Xcode CLI to run the build and test without needing Xcode Cloud? Using the github workflow yml is self-contained, so without external Xcode Cloud configuration.

[theogscott]

The way I came up with the Swift packages to create all of the dependencies was by using the Visual Studio structure and replicating it in Xcode—relatively easy. The Xcode workflow follow the Visual Studio steps ins principle.

Some background: unlike Microsoft, where the Visual Studio toolchain (the C++ compiler, etc.) is mostly proprietary, Apple uses an open‑source toolchain. This table might help your understanding what Xcode is made of

Component	Role in Xcode	Open‑source?
Clang (C/C++/Obj‑C front‑end)	Default compiler for all Apple platforms.	✅ Yes – part of LLVM, source on GitHub
LLVM (optimizer & code‑gen)	Underlies Clang; also powers Swift and other tools.	✅ Yes – same repo
LLDB (debugger)	Xcode’s debugger backend.	✅ Yes – also in the LLVM project
Swift compiler (if you write Swift)	Separate front‑end built on LLVM.	✅ Yes – open source at https://github.com/apple/swift
Xcode IDE itself (project editor, Interface Builder, UI designer)	Apple’s proprietary integrated development environment.	❌ No – not open source

If you download the Swift toolchain for Linux (or Windows), you can cross‑compile a binary that will run on macOS, and I think that what you current doing ?

However, there are a few hurdles, one that you must have the macOS SDK available for linking in the final step..

Visual Studio/Code extensions exist that support Windows and Linux, so you can use Swift Package Manager (SPM) on those platforms—I have not tried it, but is it good to know and share https://www.swift.org/install/linux/.

The SPM issue with NetLib, Sample‑Data, and miplib3
The problem SPM encounters with those three components is that their source files sit in the root of the repository.

SPM has a strict rule: a single repository may contain only one Package.swift file, and each folder must house a single type of source code (C, C++, Swift, Objective‑C, resources such as icons, header files, etc.).

If you tell the package manager that the sources are in the repository root, SPM will generate a build error when it finds a second Package.swift file. This will break the build.

From what I understand, your current workflow copies those files outside the source repo, so I am unsure how this work when app would be sandboxed. To make this work cleanly you will need to consider one of two approaches:

• Pull the repository with a shell command when Xcode performs a git pull into the build folder, or (You can also run shell command from a package.
• Use a CI/CD system (e.g., Xcode Cloud) that can perform the git pull in a sandboxed environment.
  My concern is that a CI/CD pipeline might sandbox the git pull operation, causing unexpected failures if files outside of the .git repository are accessed. I was hoping it would be easy to adjust this on the Windows/Linux side, but I may need to revisit the approach.

Managing Package.resolved and .gitignore
Package.resolved must not be checked into the repository, and it looks like it slipped in from my side. It is a file generated by Xcode that records which exact versions of dependencies were used to build the project. Some developers will, push it to their own repo it in as part of a larger separate project, as it speeds up the build process.

In Package.swift, replace the current repository URL with the URL of the COIN‑OR repository. The SPM portion of the file will be removed, and the default branch should be set to master. We will tag the repository with a version number to mark where a new release starts.

Using Xcode Cloud (or another CI/CD service)
The only reason I chose Xcode Cloud is that it costs nothing to use. You can, however, use any CI/CD service that supports the Apple ecosystem—as long as it can build with Xcode or the Xcode Command‑Line Tools (which Homebrew can install for you). If The natural thing would be to place an macOS CD/CI next to Windows /Linux

[tkralphs]

OK, thank you for the further clarifications. I'm familiar with clang and LLDB. We do test with clang on MacOS. It is XCode itself that is the main vendor-specific component that would be difficult to test against. If we could do this through Github Actions in a unified way using the Xcode CLI, then this seems to be doable. However, I still have some questions/comments.

• A big question mark is still the maintainability. All build system seems to require constant care and feeding, even for a project that is itself not changing much. Would you be just contributing this with no promise of maintaining it or would you be willing to throw up a PR when you notice something is broken, assuming that you are going to keep using this yourself and would notice?
• If we're going to do this, I think it make more sense for it to live in the Cbc project and to include the entire Cbc stack, rather than just Clp. I guess that very few people use only Clp. Would you be willing to do this for Cbc?
• The way the Visual Studio projects work is that there is a separate one for every dependency that lives in the repo with the dependency itself. In other words, CoinUtils has its own VS project files that allow the library to be built independent of Cbc/Clp, which allows testing to be done whenever changes are made to that project instead of only when changes are made to Cbc/Clp. Is a setup like this possible with XCode? Of course, another option would be run the Clp tests from within the CI of each dependency, e.g., CoinUtils, whenever a change is made to that dependency.
• Would you be willing to try to get this working within our Github Actions setup?

Thanks for the willingness to contribute this!

[theogscott]

Given that vendor-specific component is a difficult issue here, the best action would be not to merge the Xcode/Apple specific code into the master branch until there are more confidence about this action. In the mean time I would simply continue in my own forked branches, where I would optimise some subset of the code to take advantage of the Mac Silicon GPU processor vector computing capabilities, unified memory, etc. Like I have done for CoinUtuls, Osi and Clp, Cbc is also in my sights.