XCode Project File Not Generated

[TyelorD]

Hey on generating a new project with Axmol, I'm not seeing any .xcodeproj file under .proj.ios_mac folder. Am I doing something wrong when setting up Axmol, or does this file just not get created automatically anymore, and I should just create it manually in Xcode? I'm using MacOS 12.0.1, and the "release" branch of Axmol.

I am seeing the files and folders, but I don't see any "axmol" folder like Cocos2d-x use to create new projects with it's "cocos2d" folder in the project root.

Just wondering how best to get started since we are looking into potentially using this fork of Cocos since it's being maintained and Cocos2d-x isn't.

Thanks for any help you can provide!

[rh101]

Hey on generating a new project with Axmol, I'm not seeing any .xcodeproj file under .proj.ios_mac folder. Am I doing something wrong when setting up Axmol, or does this file just not get created automatically anymore, and I should just create it manually in Xcode? I'm using MacOS 12.0.1, and the "release" branch of Axmol.

The project is created via CMake. Have you tried the instructions on the front page of this repository for generating the xcode project files?

I am seeing the files and folders, but I don't see any "axmol" folder like Cocos2d-x use to create new projects with it's "cocos2d" folder in the project root.

Once you run the setup.py, an environment variable points to the root path of axmol. From there your project just uses that rather than copying the entire engine directory over to your own project.

[TyelorD]

Thanks for the reply, I'll attempt your suggestions tomorrow morning when I'm back in the office and let you know if that fixes the setup issue I'm having.

[...] and perhaps the project generation instructions need to be updated to avoid any confusion regarding this.

I personally think this is a good idea, because the way the setup instructions are written currently it appears to me that the intention is to call cmake -S . -B build -GXcode -DCMAKE_TOOLCHAIN_FILE=$AX_ROOT/cmake/ios.toolchain.cmake -DPLATFORM=OS before creating a new project (my assumption was that it was to ensure the new project had linked to the proper libraries). This especially seemed to be the case to me because they appear in the setup instructions before the command for creating new projects for C++ and Lua, plus there was no indication that those calls needed to be called from a projects root (instead I assumed it was supposed to be called from Axmol's root). Reordering the setup so that the command for building new projects is above the commands for project level IDE setup would help with that confusion, and then perhaps a small note or something mentioning that the IDE setup commands should be called from the project's root directory (and not Axmol's root directory), though perhaps that will already be more apparent just by reordering the calls in the setup instructions...

[TyelorD]

The project is created via CMake. Have you tried the instructions on the front page of this repository for generating the xcode project files?

Yeah I believe so. I ran the setup.py python script first with Python 3, and then I specifically ran the: cmake -S . -B build -GXcode -DCMAKE_TOOLCHAIN_FILE=$AX_ROOT/cmake/ios.toolchain.cmake -DPLATFORM=OS command to generate the 32 bit and 64 bit iOS libs. Then afterwards I ran: axmol new -p org.axmol.hellocpp -d D:\dev\projects\ -l cpp --portrait HelloCpp to generate a new project. The new project generated and built properly for Android, but didn't contain any .xcodeproj file in the proj.ios_mac folder in the new project.

I'm not quite sure that I understand what you mean by that. The steps you mentioned are not correct, and perhaps the project generation instructions need to be updated to avoid any confusion regarding this.

As an example for Xcode:

Step 1: Generate the project files with: axmol new -p org.axmol.hellocpp -d D:\dev\projects\ -l cpp --portrait HelloCpp

Step 2: Go into the D:\dev\projects\HelloCpp directory where the new project resides.

Step 3: Run the command from inside the root directory of your project (in this case being D:\dev\projects\HelloCpp): cmake -S . -B build -GXcode -DCMAKE_TOOLCHAIN_FILE=$AX_ROOT/cmake/ios.toolchain.cmake -DPLATFORM=OS

In the case of Android, the Android Studio IDE automatically generates the project files based on the CMake configuration, so the only thing required is to open the proj.android folder in that IDE. There is nothing to manually generate for it, which is why it worked, and had nothing to do with any commands you ran.

Once you run the setup.py, an environment variable points to the root path of axmol. From there your project just uses that rather than copying the entire engine directory over to your own project.

This seems rather bad for teams and version control. We use Perforce internally for version controlling, and so our Cocos2d-x projects always contain the "cocos2d" folder directly in the project structure, not individually for each local machine for each team member. This means each team member would need to setup the project and Axmol themselves locally on their machines, rather than being able to setup the project on one machine, and have it buildable on other team members machines by just pulling the project from version control (like Perforce).

I understand what you mean, but there is nothing preventing you from still doing that. It's only one line you need to update in your CMakeLists.txt, being this:

set(_AX_ROOT "$ENV{AX_ROOT}")

It is normally reading the environment variable named "AX_ROOT", but if you want it to use a local copy of the engine (or one in a different path altogether), then just change it to whatever you require.

For instance, to set it to a local "axmol" folder inside the project folder to one of these (I can't recall which one works):

set(_AX_ROOT ${CMAKE_CURRENT_SOURCE_DIR}/axmol) or set(_AX_ROOT ${CMAKE_CURRENT_LIST_DIR}/axmol)

When generating the project, perhaps it would be a beneficial if an extra parameter was added to the CLI to allow for the engine folder to be copied over to the generated project folder. That would also mean that the project generator would also need to apply the change to CMakeLists.txt in order to point to the correct engine path (which the generator is capable of already).

Continuing discussion from the Cocos2d-x Forums, as I'm the same person here as you were responding to on the forums with your link to this response (though that should've been relatively apparent with the unusual spelling of "Tyelor" in both places).

I got busy with other tasks and never had time to respond on if your solution worked, but your solution above to setting the _AX_ROOT environment variable still caused the AXMOL setup to create the engine source files and link them to the direct paths on my machine in the generated Xcode project. The Xcode project also did not compile with numerous errors due to changing the _AX_ROOT variable. On a new project without changing that variable, the project then compiled normally, but again it was still pointing to the Axmol source on my machine. I need the Axmol root to be a relative path to the project's source directory, this way when a team member pulls the project off Perforce into their respective machine (and thus respectively named workspace) the Xcode project file is still pointing directly to that Axmol source on their machine that they just pulled as a part of the project.

As far as I could tell the default setup for Axmol currently doesn't support this, and I was unable to get this to work after following your advice, leading me to make the statements that I did about ease of collaboration and being for solo/small developers. It was my expectation that setup would work virtually identically to that of Cocos2d-x's, where the setup script creates the Cocos2d-x source code into the project structure, and links the game project to that relative Cocos2d-x project.

I apologize if my original question made this unclear, or if I've somehow totally misunderstood what you've written.

[rh101]

Continuing discussion from the Cocos2d-x Forums, as I'm the same person here as you were responding to on the forums with your link to this response (though that should've been relatively apparent with the unusual spelling of "Tyelor" in both places).

That was quite apparent ;)

I got busy with other tasks and never had time to respond on if your solution worked, but your solution above to setting the _AX_ROOT environment variable still caused the AXMOL setup to create the engine source files and link them to the direct paths on my machine in the generated Xcode project. The Xcode project also did not compile with numerous errors due to changing the _AX_ROOT variable. On a new project without changing that variable, the project then compiled normally, but again it was still pointing to the Axmol source on my machine.

That shouldn't be happening, and needs to be fixed. I'll try to reproduce it on my own system and try to figure out why it's not working as intended. We need the flexibility to be able to change the path to the game engine.

I need the Axmol root to be a relative path to the project's source directory, this way when a team member pulls the project off Perforce into their respective machine (and thus respectively named workspace) the Xcode project file is still pointing directly to that Axmol source on their machine that they just pulled as a part of the project.

CMake-generated project files should never be checked into source control. Everything required to generate the correct project should exist within the CMakeLists.txt, and it should always be reproducible. The whole point is that they are generated when required. Is there any particular reason you need those files in source control?

Also, did the Xcode project files generated by cmake in Cocos2d-x v4 on one machine somehow work on multiple machines, when checked out to a different path than the originally generated project?

As far as I could tell the default setup for Axmol currently doesn't support this, and I was unable to get this to work after following your advice, leading me to make the statements that I did about ease of collaboration and being for solo/small developers. It was my expectation that setup would work virtually identically to that of Cocos2d-x's, where the setup script creates the Cocos2d-x source code into the project structure, and links the game project to that relative Cocos2d-x project.

The main issue is that the problem with _AX_ROOT, and that needs to be fixed. Regarding adding the cmake-generated project files to source control, that isn't a bug, because those files should always be re-generated when required. If there is some manual change you have to do to the project files after cmake generates them, then that should be addressed, because anything you need should be done in CMakeLists.txt.

I apologize if my original question made this unclear, or if I've somehow totally misunderstood what you've written.

Now I understand what you mean, and I didn't realise that part of your process was to add the cmake generated project files to source control.

[rh101]

I've just tested this on Windows, and it worked as intended, although I did come across a minor issue that has now been fixed in #989

Here are the steps I used to test it out:

1- Clone game engine from github into C:\axmol
2- Setup the game engine using setup.py etc.
3- Generate project using the axmol command, so it generates C:\Projects\testproject
4- Copy the axmol engine folder to a sub-directory in the project folder, so this case, I named it "axtest", so it would exist in: C:\Projects\testproject\axmol.
Note that you should avoid copying the templates and test axmol sub-folders, since they're huge and are not required.
5- In order to ensure that the original folder the engine was cloned to from github isn't used, I renamed it to C:\axmol_old
6- In the root CMakeLists.txt of the new project, I changed the following:
set(_AX_ROOT "$ENV{AX_ROOT}")
to
set(_AX_ROOT ${CMAKE_CURRENT_SOURCE_DIR}/axtest)

7- I then ran the following command to generate the required out-of-source project files:
cmake -S . -B build-win64-vs2022 -G "Visual Studio 17 2022" -A x64

This generated a folder named build-win64-vs2022, which contains the Visual Studio 2022 project files.

The generated project was opened in VS2022, building and running successfully. At no point did it try to reference the original C:\axmol\ folder during the build, so there were no errors.

The next step will be to test this out on a Mac, which I may not have time to do today.

@TyelorD If there is anything you can see on your end that is causing the issue, or even check the [buildfolder]\CMakeCache.txt file for incorrect path references, then that would help.

[TyelorD]

@rh101 Thank you for the detailed response! We've been busy with the holidays (Happy New Year to you) and a bug fix update for one of our games at the moment, so I haven't had time to test your steps on my Mac yet (which is where I develop, since it makes it easier to release our apps to the Apple App Store).

Once I do have the time to test it, I'll respond here letting you know whether or not it worked for us and provide logs/cache files in the case that it doesn't 😄

[rh101]

@TyelorD CMake has new functionality that may help with your multi-developer and CI builds. Info is here: https://cmake.org/cmake/help/v3.24/manual/cmake-presets.7.html