Axmol build time improvement

[asnagni]

Is your feature request related to a problem? Please describe. I'm always frustrated when I make a modification in my code and everything will get rebuild. I'm wasting about 15 minutes each time a make a simple change even if it's a single line code I'm changing. It's not acceptable in a production environment.

Describe the solution you'd like The solution would be to use ccache. ccache (https://ccache.dev/) is a compiler cache that can drastically improve the build time for C and C++ projects and it is hosted here (https://ccache.dev/). This solution could be added in the CMake templated file and it will get automatically activated if the developer install ccache. Please see pdf

AxmolBuildTime.pdf

Describe alternatives you've considered ccache is the best solution out there and wildly used. So it's difficult to come with alternative. But I would be more than happy to know if there is an alternative out there

Additional context N/A

[rh101]

This should be a discussion post, or a wiki post, as this isn't an issue with Axmol. The use of ccache is entirely up to the developer.

The purpose of the template is to serve as a starting point for developers, with the intention being that the developer modify the project files to suit their requirements.

IMHO, adding items unrelated to Axmol into the template is not a good idea, because it adds extra "noise", and becomes yet another item that needs to be maintained.

Also, if you do add a wiki post about this, please don't add the PDF file, but just post the text directly in a wiki page.

[asnagni]

Hi Rh101, I'm not 100% sure to agree that this is not an Axmol issue. It used to take us about 2 minutes to build with cocos2d-x when we made any modifications. After migrating our project to Axmol the build time went up to 15 minutes.

Having a building time of 15 minutes and having everything rebuild even if you change a single line of code I think this is a Axmol platform issue. This needs to be address.

I will agree with you that we may need a different solution to fix the issue. That said, the solution that I'm proposing doesn't force the developers to install ccache. Like I mentioned in the pdf file, If they don't install ccache it will be transparent, nothing will change for them, the build time will long as usual.

For the template, I do understand the goal, but I'm sure that anyone would like to have a short build time cycle. Nobody would want to spend 15 minutes building because they changed a single line of code. That's a giving.

So my question to you would be how would you like to address the long build time problem. From my understanding Axmol is aiming to be an improvement of coco2d-x, right? The build issue doesn't exist with cocos2d-x, perhaps we can use the same solution that they have if you don't like ccache approach? What do you think?

Again, I want to make sure that you understand that I like the Axmol initiative, and I'm supportive of this work. I'm just trying to help to improve things that may be a blocker for some people that would like to make the move.

Thank you. Stay safe

[rh101]

I'm not 100% sure to agree that this is not an Axmol issue.

Sorry, I wasn't quite clear. I didn't mean the Xcode issue is not related to Axmol, but rather that ccache is unrelated to the use of Axmol.

It used to take us about 2 minutes to build with cocos2d-x when we made any modifications. After migrating our project to Axmol the build time went up to 15 minutes.

I'm not entirely sure why this is happening, but as far as I can tell, it's only happening with Xcode. It does not happen when creating Windows or Android builds. Perhaps it would be better to find the actual source of this problem than to work-around it with ccache; that is not to say that ccache isn't worthwhile using, it is, but in the end that would be a choice for the developer using Axmol.

That said, the solution that I'm proposing doesn't force the developers to install ccache. Like I mentioned in the pdf file, If they don't install ccache it will be transparent, nothing will change for them, the build time will long as usual.

As I mentioned previously, the change is not related to the use of Axmol with the project; any developer wishing to use it can simply modify the CMakeLists.txt in their project once it's created. It's not like the template is used constantly; the project is generated once, and that's it, so it's definitely not adding a burden on developers.

Adding that unrelated code to the template would place the burden on the maintainers of the project, since that small bit of code still needs to be maintained into the future.

So my question to you would be how would you like to address the long build time problem.

The right thing to do would be to find the underlying issue with Xcode builds, and fix that.

From my understanding Axmol is aiming to be an improvement of coco2d-x, right? The build issue doesn't exist with cocos2d-x, perhaps we can use the same solution that they have if you don't like ccache approach? What do you think?

Axmol is a continuation and improvement in terms of functionality and support, and while the API may be somewhat compatible, the code-base has diverged significantly (particularly thirdparty modules). These differences would have some effect on build times, but the build times are not a reflection on whether one engine is better than the other.

Documentation, such as the wiki, is there for developers to learn both about Axmol and things that may be useful to them when working with Axmol. Adding a section regarding improving build times is a perfect fit for that, whether or not we discover the true issue causing the long build time in Xcode.

Also, just out of curiousity, what are the specs of the Mac used for compilation (CPU/memory etc.)?

[smilediver]

I also agree that the focus should be on figuring out why rebuilds are happening, because ccache doesn't fix the issue, it just scales it down.

[asnagni]

Hi guys, Thank you for the feedback, I do really appreciate. I think we are all on the same page here. At the end of the day we want the same thing, which is have an awesome system and people are having fun coding 😊👍.

So from my understanding, we have 2 action items: 1) Action item 1: Based on rh101 proposal, I will publish the ccache solution as a workaround on a wiki page to help anyone that may be facing the same problem. It will help them speed up their build process by a factor 8 minimum.

2) Action item 2: We will not close the open item and investigate to find a better solution to the problem.

Please let me know if my understanding is correct.

Thank you guys, Stay safe

[asnagni]

I'm not 100% sure to agree that this is not an Axmol issue.

Sorry, I wasn't quite clear. I didn't mean the Xcode issue is not related to Axmol, but rather that ccache is unrelated to the use of Axmol.

It used to take us about 2 minutes to build with cocos2d-x when we made any modifications. After migrating our project to Axmol the build time went up to 15 minutes.

I'm not entirely sure why this is happening, but as far as I can tell, it's only happening with Xcode. It does not happen when creating Windows or Android builds. Perhaps it would be better to find the actual source of this problem than to work-around it with ccache; that is not to say that ccache isn't worthwhile using, it is, but in the end that would be a choice for the developer using Axmol.

That said, the solution that I'm proposing doesn't force the developers to install ccache. Like I mentioned in the pdf file, If they don't install ccache it will be transparent, nothing will change for them, the build time will long as usual.

As I mentioned previously, the change is not related to the use of Axmol with the project; any developer wishing to use it can simply modify the CMakeLists.txt in their project once it's created. It's not like the template is used constantly; the project is generated once, and that's it, so it's definitely not adding a burden on developers.

Adding that unrelated code to the template would place the burden on the maintainers of the project, since that small bit of code still needs to be maintained into the future.

So my question to you would be how would you like to address the long build time problem.

The right thing to do would be to find the underlying issue with Xcode builds, and fix that.

From my understanding Axmol is aiming to be an improvement of coco2d-x, right? The build issue doesn't exist with cocos2d-x, perhaps we can use the same solution that they have if you don't like ccache approach? What do you think?

Axmol is a continuation and improvement in terms of functionality and support, and while the API may be somewhat compatible, the code-base has diverged significantly (particularly thirdparty modules). These differences would have some effect on build times, but the build times are not a reflection on whether one engine is better than the other.

Documentation, such as the wiki, is there for developers to learn both about Axmol and things that may be useful to them when working with Axmol. Adding a section regarding improving build times is a perfect fit for that, whether or not we discover the true issue causing the long build time in Xcode.

Also, just out of curiousity, what are the specs of the Mac used for compilation (CPU/memory etc.)?

Hi rh101, Thank you for you reply, it's pretty clean and clear. Having the information you provided, I agree with you, it will not be a good solution to put that in the template CMake file.

Thank you, Stay safe

[rh101]

I'm always frustrated when I make a modification in my code and everything will get rebuild. I'm wasting about 15 minutes each time a make a simple change even if it's a single line code I'm changing.

Using latest Axmol (current dev branch), Xcode 15.0.1 and CMake 3.29.1, I've attempt many tests so far, changing code in C++, ObjC and Swift source files, and not once has the project re-built from scratch. Is there a step missing from your instructions on how to reproduce this issue?

Here is exactly what I attempted on an existing large project: 1 - Run axmol build -p ios -c 2 - Add a CocoaPods file 3 - Run pod init then pod install --repo-update 4 - Open <project>.xcworkspace in Xcode 5 - Build and run project on device 6 - Stop execution of application on device 7 - Change a few C++, Swift and ObjC files 8 - Build and run project. Only the changed files are re-compiled (very quick). The bit the took the longest (approx 20 secs) was generating the <project>.dSYM file.

@asnagni What steps am I missing in order to reproduce the issue?

Another test: 1 - Add new source files to project via entries in CMakeLists.txt, named "TestFile.cpp"/"TestFile.h" 2 - Run axmol build -p ios -c to update project files 3 - Run pod install --repo-update to update workspace 4 - Close workspace in Xcode if already open, and then re-open workspace 5 - Build project. Only "TestFile.cpp" was built, and new dSYM file generated. Entire process took approx 30 seconds.

[asnagni]

Hi rh101, Thank for your reply and also thank you for taking the time to look into this issue. I’m not sure but I don’t think that we are doing anything wrong as far as I know. That said, since we are new to Axmol, you never know. I will give all the information that I have, that may help narrow down the issue.

So we are located in two different places. I’m in the USA (New York) and my counterpart is in Hong Kong

This is the equipment and settings that we have:

For me (in New York):

1) My computer: MackBook Pro 2.4 GHZ 8 core Intel core i9 (please see attachment)

2) Xcode: version 15.3 3) CMake: 3.29.0

In Hong Kong:

1) His computer: MackBook Pro 1.99 GHZ 4 core Intel core i7 (please see attachment)

2) Xcode: version 15.3 3) CMake: 3.29.0

This is the process that we followed to create and test Axmol engine:

Phase 1: Installation of Axmol engine

1) Downloaded the latest release version (2.1.2) 2) unzipped the file. We got the folder axmol-2.1.2 3) We CD into the folder axmol-2.1.2 4) Launched the Terminal and enter the command: pwsh setup.ps1 5) Once the build process was over, we closed the terminal

Phase 2: Creation of the Axmol project structure 1) We created a folder that we called AxmolPojects 2) We cd in the the AxmolPojects folder 3) we launched the Terminal and issued the command: pwsh 4) After that, we issue the command: axmol new -p YOUR.UNIQUE.ID -d PROJECT_PATH -l cpp PROJECT_NAME 5) Once the project structure was done, we cd into the Axmol project directory PROJECT_NAME

Phase 2: Creation of the iOS project 1) from in the project directory we issued the command: axmol build -p ios -a arm64 -c 2) We copied our pod file into the directory build_ios_arm64 3) we cd in the directory build_ios_arm64 4) we issued the command: pod install 5) Once the process was over, we closed the Terminal and clicked on .xcworkspace local in the build_ios_arm64 folder

Results In Hong Kong (before migrating our code): 1) In Hong Kong the build time takes about 13 minutes. 2) When they make a change everything will be rebuilt (even if a single line of code is changed)

Results In New York (before migrating our code): 1) In New York the build time takes about 7 minutes. 2) When we make a change everything will be rebuilt (even if a single line of code is changed)

With ccache integrated: In Hong Kong and in New York, depending on the change that is performed, the build time will be between 52s to at most 1min 20 seconds (only what changed will be build).

Please let me know if there is anything I can do to help narrow down the issue.

Thank you, Stay safe

[rh101]

• from in the project directory we issued the command: axmol build -p ios -a arm64 -c

• We copied our pod file into the directory build_ios_arm64

• we cd in the directory build_ios_arm64

Thanks for the information. Just one thing thing that may cause you issues is that you shouldn't be adding the pod file to the build folder. The build folder is temporary, and shouldn't have any file manually placed in there that belongs to the project, especially a file you will be checking into your source control (such as the pod file).

Now, with regards to the pod file, it should be placed in the root folder of your project, and in it, set the "project" line as follows (based on your "PROJECT_NAME" example above):

project './build_ios_arm64/PROJECT_NAME.xcodeproj'

You no longer need to copy it into the build folder. If you need to support multiple architectures, then use text replacement for a Podfile.in (m4 macro preprocessor etc.), which will generate the Podfile automatically based on the build folder. Look into CMake configure_file.

An example of that would be the code the CMakeLists.txt which is used for Windows builds to generate the run.bat file:

# config quick starter batch script run.bat for windows
if(WIN32)
    file(RELATIVE_PATH CMAKE_BUILD_RELATIVE_DIR "${CMAKE_CURRENT_SOURCE_DIR}" "${PROJECT_BINARY_DIR}")
    configure_file("${CMAKE_CURRENT_SOURCE_DIR}/run.bat.in" "${CMAKE_CURRENT_SOURCE_DIR}/run.bat" @ONLY)
endif()

It should replace the project './[TEXT_TO_REPLACE]/PROJECT_NAME.xcodeproj', so the generated Podfile is the one you need, and the only thing you add to your source control is the Podfile.in.

I'm not sure if this would make any difference to your builds, but based on the info you posted, the only real difference is the OS and Xcode versions. I'll update my Mac to Sonoma 14.4.1 and Xcode 15.3, and do the test again in a day or so.

[rh101]

• After completing the first build I change randomly a line of code and build. It was fast to build. Only the file changed was build.

• After that, I did multiple tests and I can confirm that the problem is solved.

That is excellent news!

7. When the process was completed I launch the project by clicking on “PROJECT_NAME.xcodeproj” file

When you use Cocoa Pods with your project, you should be loading the PROJECT_NAME.xcworkspace in Xcode, instead of the .xcodeproj. Is that what you meant?

Regardless, I'm really glad it is working now.

If you're certain that this is resolved, then please close this issue. :)