Can't add package to XCode project

[udirub]

• axmol version: 2.1.3
• devices test on:
• developing environments: XCode 15.4
  Steps to Reproduce:

1. Create a new project (axmol new -p com.new.www -d ./ -l cpp Coloring -i)
2. Create an XCode project for the project (axmol build -p ios -a arm64 -c)
3. Try to add a package dependency to the project, specifically: https://github.com/tikhop/ASN1Swift
4. XCode stuck on "Preparing to validate..."

If I create a new random project in XCode I can add the package with no problem.

[udirub]

Just tested on axmol 2.1.4 and the problem persists.

[smilediver]

I don't know how packages work in Xcode, but if they integrate into your Xcode project, then they will be gone the next time Xcode project is regenerated (e.g. after adding new source files, etc). This is not how Axmol workflow works. You should treat generated Xcode project as "readonly". You'll probably want to look into something that can be integrated from command line like CocoaPods.

[udirub]

Oh...
So it's not like the XCode project Cocos2d-x made where I edited it directly?

[rh101]

So it's not like the XCode project Cocos2d-x made where I edited it directly?

Cocos2d-x v3.17+ and V4 both use cmake, which generate the Xcode project, and Axmol also uses the cmake build system, so nothing has changed in that regard. If you're referring to v2 of Cocos2d-x. then yes, a lot has changed. Anything you want to add to the Xcode project would need to be done via cmake or CocoaPods.

The ASN1Swift project you linked has an example of how to add it via CocoaPods.

[smilediver]

To expand on this: yes, you should not edit Xcode project directly, and do not add it to your source control. Basically, you want to have an easy runnable two steps setup:

1. Generate Xcode project - axmol build -p ios -a arm64 -c or similar.
2. Modify Xcode project - your custom automated step that makes the changes to the Xcode project. This could be done using CocoaPods or something else.

I was a bit wrong to say "treat generated Xcode project as "readonly"". You can certainly modify it, but it must be automated, cause you will lose changes the second that you modify CMake files, or CMake runs ZERO_CHECK task for some reason. It also hardcodes paths, so you would not be able to build that project on another machine, or if you moved your project to another folder.

Also, be aware that if you're running build in Xcode after editing CMake files (or if CMake reruns ZERO_CHECK task for some other reason), then Xcode project will be regenerated during the build, and Xcode will notice it and it will cancel the build to reload it. Then you need to execute your step 2, since your Xcode project changes will be gone, and then restart the build.

[udirub]

So it's not like the XCode project Cocos2d-x made where I edited it directly?

Cocos2d-x v3.17+ and V4 both use cmake, which generate the Xcode project, and Axmol also uses the cmake build system, so nothing has changed in that regard. If you're referring to v2 of Cocos2d-x. then yes, a lot has changed. Anything you want to add to the Xcode project would need to be done via cmake or CocoaPods.

The ASN1Swift project you linked has an example of how to add it via CocoaPods.

I am working with cocos 3.10 which created an XCode project when I created the project and I've been working on it directly all the time and it worked fine. I thought I could do the same with axmol.

[udirub]

To expand on this: yes, you should not edit Xcode project directly, and do not add it to your source control. Basically, you want to have an easy runnable two steps setup:

1. Generate Xcode project - `axmol build -p ios -a arm64 -c` or similar.

2. Modify Xcode project - your custom _automated_ step that makes the changes to the Xcode project. This could be done using CocoaPods or something else.

I was a bit wrong to say "treat generated Xcode project as "readonly"". You can certainly modify it, but it must be automated, cause you will lose changes the second that you modify CMake files, or CMake runs ZERO_CHECK task for some reason. It also hardcodes paths, so you would not be able to build that project on another machine, or if you moved your project to another folder.

Also, be aware that if you're running build in Xcode after editing CMake files (or if CMake reruns ZERO_CHECK task for some other reason), then Xcode project will be regenerated during the build, and Xcode will notice it and it will cancel the build to reload it. Then you need to execute your step 2, since your Xcode project changes will be gone, and then restart the build.

I have never worked directly with CMake. I created my project with cocos 3.10 and it created an XCode project and I've done all my work through XCode and it worked great.
Is there a way to work with axmol the same way?

[smilediver]

I think you're talking about the old way how Cocos worked, when it generated Xcode project from a template and it was up to you to maintain it. Later Cocos switched fully to CMake, and Axmol inherited this. Now you use CMake to generate projects when you need them to work on or build your game.

Unfortunately, there's no other way. If you will choose to bypass CMake, then you will not be able to update the engine anymore, and probably run into a lot of other issues too. Also it hardcodes full paths to files in the project, and you will not be able to work with this project on other machines or even other folders.

[rh101]

I am working with cocos 3.10 which created an XCode project when I created the project and I've been working on it directly all the time and it worked fine. I thought I could do the same with axmol.

When the cmake build system was added to Cocos2d-x v3, the intention was never to use it in the way you are describing, and you would not be doing yourself any favors by attempting to continue working in this way. The fact that it worked without issues is purely by chance.

Embracing the cmake build system should make things simpler and less time consuming, especially if you wish to support multiple platforms for your application.

@halx99 I feel that this should be moved to the discussion section, since it's not an issue with Axmol.

[GamesStudioTwo]

Xcode is a pain in the butt, you can work on a project for months then all of a sudden, You mite have to reimport the apple license all over again as xcode just throws it out for no reason or the settings just change for no reason. apple keep updating the compile all the time then its a problem to get XCode to compile again. I seem to be spending more time sorting out apple problems and xcode then programming. This is why I program android then ill recompile at the end of project for Xcode.

[smilediver]

I recommend trying out VSCode for editing and Ninja for building, and mainly develop on desktop (Windows or macOS) builds, and build your game for Android or iOS only if you need to test them out. Iteration times are a lot faster this way.

[udirub]

I've been working on various cocos projects in xcode for almost a decade and it worked pretty smoothly. That's why I'm surprised to learn that's not the "correct" way.
But if axmol doesn't work that way I'll try the cmake way.
Thanks all.