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?

[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.