Fix Xcode project build failures

[jack68k]

Your checklist for this pull request

• [ n/a ] I've documented or updated the documentation of every API function and struct this PR changes.
• [ n/a ] I've added tests that prove my fix is effective or that my feature works (if possible)

Detailed description

Previously, the Xcode project failed to build due to being out-of-sync with C sources that have been added or removed.

Now:

• All 3 library targets build successfully: static library, dynamic library, and macOS framework bundle.
• The project contains all .c sources from the root directory and arch/*.
• .h and .inc files are removed as they were very out-of-sync with the actual filesystem. The files that previously existed were not included in any target and do not need to be present in the project tree to for build.
• Removed obsolete test targets that referenced source files that were deleted when modern testing was introduced.
• Updated the xcode/README.md to reflect the current state.

No sources, headers, or tests were modified.

Test plan

Verify that all 3 targets in the Xcode project build successfully. The simplest way is to use xcodebuild:

xcodebuild -target CapstoneStatic -configuration Release
xcodebuild -target CapstoneDynamic -configuration Release
xcodebuild -target CapstoneFramework -configuration Release

Closing issues

I did not find any associated issues.

[Rot127]

I can't test it. But seems fine. I'll ask one of the others if they can take a look.

[b1llow]

It compiles successfully, but it seems to have completely deleted the tests from the Xcode project?

It also lacks support for later-added architectures such as Tricore.

On macOS, you can use the Xcode generator to create an Xcode project (cmake -G Xcode -B cmake-xcode), but the Xcode project generated by default fails to compile when using xcodebuild -alltargets.

/Users/aya/workspace/capstone/utils.c:194:15: error: implicit conversion loses integer precision: ‘long’ to ‘int’ [-Werror,-Wshorten-64-to-32]
  194 |         int i = dest - str;

I think it’s perfectly fine to delete the current outdated Xcode project files and instead ensure that the code compiles (using the Xcode project generated by CMake).
However, if we don’t add this to CI, it will quickly become outdated as well.

[Rot127]

However, if we don’t add this to CI, it will quickly become outdated as well.

@jack68k If you could add a workflow and docs for it it would be awesome!

[jack68k]

Thank you for the feedback. Here are my overall thoughts on maintaining an Xcode project.

I think the value in having an Xcode project at all is to provide an idiomatic way to integrate the Capstone library into a consuming project that's being developed in Xcode on macOS. This opens the door to source-level debugging of Capstone, if needed.

In this scenario, one approach to consuming the Capstone library is to add it as a git submodule and then add Capstone's Xcode project to your workspace. This makes it easy to build the library as part of your consuming project's build process, and to choose which of the macOS targets you want to link with: the static library, the dynamic library, or most idiomatically on macOS, the .framework because it encapsulates both the library and the public headers.

Certainly there are alternatives such as creating a custom build script that pulls and builds the Capstone library in a directory that's ignored by git, or committing the library artifacts and public headers to the consuming project's source tree. Opinions differ on the best way to handle this, and there are significant drawbacks to every approach. I personally prefer the submodule approach when possible.

Since the native build system for Capstone is CMake, it doesn't make sense to try to use Xcode for actual Capstone library development on macOS. You'd be better off choosing an IDE that has support for CMake such as Visual Studio Code (it has an extension, of course), or just use your favorite text editor + command line builds.

So, back to the Xcode project. I would propose:

• Include all supported disassembly architectures -- thank you for pointing out the omission of several architectures.
• Provide targets to build the static library, dynamic library, and .framework.

Out of scope:

• Build cstest
• Run tests
• Build cstool

Unfortunately, there's not a good way to generate or sync an Xcode project with the source of truth, CMakeLists.txt.

• @b1llow noted that cmake -G Xcode -B cmake-xcode does not produce a functional project.
• There are a couple of other tools out there for generating Xcode projects that have similar gaps.
• Xcode does have the concept of folders that are in sync with the file system, but this only affects whether the files are displayed in the file list. You still have to manually specify which source files are part of a build target. So new source files would have to be added manually.

So, custom scripting would be needed to produce a project that's in sync with CMakeLists.txt.

Alternatives

I'm wondering if it would be best to remove the .xcodeproj from Capstone's source tree entirely and go with a different approach.

Idea 1: Separate Project

Someone maintains a separate project on GitHub that provides the .xcodeproj and references Capstone as a git submodule. New commits to Capstone would be pulled in manually and the .xcodeproj would be updated.

Pros:

• Stability. The Xcode project can't break because it is decoupled from new commits.
• Consuming projects maintain the ability to do source-level debugging (step into Capstone code if needed)

Cons:

• Someone has to maintain it for it to stay up-to-date; it's not naturally maintained as part of the core project.

Idea 2: Pre-built package

There is a Capstone homebrew package however it only provides released versions. Since there's a lot of active development, it would be helpful to have nightly packages or packages built from other tags.

Pros:

• Builds Capstone using CMake, its native build system + some scripting to produce the package.
• I believe this is automatable using GitHub actions
• Could be in the Capstone repo or a completely separate project that pulls Capstone's sources and builds the package.

Cons:

• No source-level debugging for consuming projects.

I know this is a lot -- I look forward to your thoughts.

[Rot127]

This opens the door to source-level debugging of Capstone, if needed.

Sorry, I never got into the Apple ecosystem so far and struggle to find a quick answer for myself.
Could you please elaborate why only Xcode developed projects allow source code debugging?
Doesn't have Xcode some kind of "build external dependency with commands xyz" functionality?

I'm wondering if it would be best to remove the .xcodeproj from Capstone's source tree entirely and go with a different approach.

This seems the best option IMHO.
We had a discussion about adding meson build and I think also about Visual Studio (can't find the PR/issues currently).
And IIRC always decided to better boil it down to cmake only. To not have too much maintenance burden.

Separate Project

If someone maintains it it would be good. It maybe wouldn't need to be update for each commit? Only for each release?

There is a Capstone homebrew package however

It doesn't seem to pick up the latest Alpha releases sadly.