Build time too long when we re-run the App

[asnagni]

When we re-run our App without changing (no code change), everything will build again. That a long wasted. Maybe there is an option in Axmol to avoid this situation? No sure why this happening!

• axmol version: 2.1.2
• devices test on: iPhone 11, 12 , 13, 14
• developing environments
  • NDK version: N/A
  • Xcode version: N/A
  • Visual Studio:
    • VS version: N/A
    • MSVC version: N/A
    • Windows SDK version: N/A
  • cmake version:
    Steps to Reproduce:

1. Create an Axmol project
2. Add your files
3. Build
4. Run your App.
5. Stop the App (via Xcode)
6. Run the App from you device (Do not use Xcode)
7. Stop the App
8. Run your App again with Xcode
9. Everything will be rebuilt again

[asnagni]

Hi guys,
I have a way to solve this issue. Now the build is 8x to 10x faster. Only what changed will be rebuild and no rebuild of the Axmol libraries. It is as fast as cocos2d-x and in some cases faster.
I do believe that this should should be included in the Axmol template build. That will help convert more people to the Axmol platform .

How can I share the solution that I have?

Thank you.

[asnagni]

Should I create one feature request?
Use this entry?

Feature request: Suggest an idea for this project

[danialias]

Have you tested this issue with other not-Axmol projects? It may be a Xcode problem.

I found a similar question in Reddit: https://www.reddit.com/r/iOSProgramming/s/63mUKEZ630

[asnagni]

This is the document that I have to significantly improve Axmol build time. That may help anyone that would like to improve their productivity.

AxmolBuildTime.pdf

[rh101]

I haven't managed to reproduce this specific issue at all, with either an existing project or a new project. The application is never rebuilt after step 8, it just simply runs on the device.

Using Xcode 15.0.1

[paulocoutinhox]

Hi,

I have the same problem on Xcode and not on Android.

I see this more when add cocoapods dependency that use ObjC bridge, like RevenueCat framework.

[rh101]

This issue has started happening now, and I'm not sure what triggered it. On rare occasions it doesn't rebuild everything, but the majority of the time it does, which means 5+ minutes of building everything when only single line is changed in the game project C++ source (not even a header change). This shouldn't be happening at all, and it's only an issue with Xcode (VS and Android Studio builds do not have this problem).

[paulocoutinhox]

Hi, i have the same problem. What im doing is build/develop on Android Studio that dont have this problem and build for iOS/tvOS only to publish or final test.

[rh101]

Hi, i have the same problem. What im doing is build/develop on Android Studio that dont have this problem and build for iOS/tvOS only to publish or final test.

I understand, but that's not really the issue here. For me personally, 99%+ of my development is in Visual Studio, which allows me to be more productive than when using any other IDE.

The issue is having to work on very specific iOS/MacOS related code, and unfortunately, there is no way to avoid Xcode for this.

I'm yet to figure out what is causing the unnecessary re-builds, even when there are no changes at all to the project.

[smilediver]

Question for those experiencing this problem: are you using CocoaPods in the project and are you using this hack set_xcode_property(${APP_NAME} CONFIGURATION_BUILD_DIR "\$(BUILD_DIR)/\$(CONFIGURATION)\$(EFFECTIVE_PLATFORM_NAME)")?

[paulocoutinhox]

There is any way to set it from podfile? Since the workspace is generate by it?

[paulocoutinhox]

I know that there is a command line for this:

xcodebuild -workspace Foo.xcworkspace -scheme Bar -configuration Release -archivePath /path/to/Foo.xcarchive clean archive -UseModernBuildSystem=NO

[paulocoutinhox]

when you update the Xcode->File->Project Settings->Build System = Legacy Build System, it updates Projectname.xcodeproj/project.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings.

<dict>
	<key>BuildSystemType</key>
	<string>Original</string>
</dict>

when you set it to "New Build System", this file does not have this block

[paulocoutinhox]

Based on this, i add this to my makefile rule:

build-ios:
	rm -rf build_ios_arm64/
	axmol build -p ios -a arm64 -c
	cd build_ios_arm64 && pod install
	cd build_ios_arm64/${PROJ}.xcworkspace && mkdir -p xcuserdata/$(USER).xcuserdatad && \
	plutil -create xml1 xcuserdata/$(USER).xcuserdatad/WorkspaceSettings.xcsettings && \
	plutil -insert BuildSystemType -string Original xcuserdata/$(USER).xcuserdatad/WorkspaceSettings.xcsettings && \
	plutil -insert BuildLocationStyle -string UseTargetSettings xcuserdata/$(USER).xcuserdatad/WorkspaceSettings.xcsettings

[smilediver]

Build location and build system are two different things. As far as I can tell, this rebuilding issue is caused by the build location and not the build system choice. Also the legacy build system is deprecated and will be removed.

[asnagni]

Hi, 1) Yes using cocoapods. 2) Yes using the hack : set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CONFIGURATION_BUILD_DIR "\${BUILD_DIR}/\$(CONFIGURATION)\$(EFFECTIVE_PLATFORM_NAME)”) Thank you, Stay safe

…

On Jul 12, 2024, at 1:45 PM, smilediver ***@***.***> wrote: Question for those experiencing this problem: are you using CocoaPods in the project and are you using this hack set_xcode_property(${APP_NAME} CONFIGURATION_BUILD_DIR "\$(BUILD_DIR)/\$(CONFIGURATION)\$(EFFECTIVE_PLATFORM_NAME)")? — Reply to this email directly, view it on GitHub <#1885 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI54DTG5HBB6QBHRMC5ID2TZMAI2JAVCNFSM6AAAAABJLLNUQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBTGQZTIMI>. You are receiving this because you authored the thread.

[paulocoutinhox]

I have this too:

if(APPLE)
    if(TVOS)
        set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CONFIGURATION_BUILD_DIR "\${BUILD_DIR}/\$(CONFIGURATION)\$(EFFECTIVE_PLATFORM_NAME)")
        configure_file("${CMAKE_CURRENT_SOURCE_DIR}/Podfile.tvos" "${CMAKE_CURRENT_BINARY_DIR}/Podfile" COPYONLY)
    elseif(IOS)
        set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CONFIGURATION_BUILD_DIR "\${BUILD_DIR}/\$(CONFIGURATION)\$(EFFECTIVE_PLATFORM_NAME)")
        configure_file("${CMAKE_CURRENT_SOURCE_DIR}/Podfile.ios" "${CMAKE_CURRENT_BINARY_DIR}/Podfile" COPYONLY)
    endif()
endif()

But i have the same problems. When i change one line of code, it rebuild near everything and take a long time too build.

[asnagni]

Hi there, Yes I remember this issue when I migrated to Axmol. It can cost you lot of valuable time. I posted a solution to solve this problem and it works 100%. Since then I don’t have to worry anymore about it anymore. I posted a pdf document that show you how to mitigate the problem. Take a look at it, it will save you lot of time. When The Axmol will come up with a better solution, you can swap to their solution/proposal. Thank you, Stay safe

…

On Jul 13, 2024, at 12:43 PM, Paulo Coutinho ***@***.***> wrote: I have this too: if(APPLE) if(TVOS) set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CONFIGURATION_BUILD_DIR "\${BUILD_DIR}/\$(CONFIGURATION)\$(EFFECTIVE_PLATFORM_NAME)") configure_file("${CMAKE_CURRENT_SOURCE_DIR}/Podfile.tvos" "${CMAKE_CURRENT_BINARY_DIR}/Podfile" COPYONLY) elseif(IOS) set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CONFIGURATION_BUILD_DIR "\${BUILD_DIR}/\$(CONFIGURATION)\$(EFFECTIVE_PLATFORM_NAME)") configure_file("${CMAKE_CURRENT_SOURCE_DIR}/Podfile.ios" "${CMAKE_CURRENT_BINARY_DIR}/Podfile" COPYONLY) endif() endif() But i have the same problems. When i change one line of code, it rebuild near everything and take a long time too build. — Reply to this email directly, view it on GitHub <#1885 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI54DTGHQYKD4CAREEAPF4TZMFKMBAVCNFSM6AAAAABJLLNUQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBTHE4DSMY>. You are receiving this because you authored the thread.

[asnagni]

Hi , I couldn’t build without the hack. Stay safe.

…

On Jul 15, 2024, at 6:57 AM, smilediver ***@***.***> wrote: Did you find that CONFIGURATION_BUILD_DIR is causing the rebuild issue, or you couldn't build the project without it? If CONFIGURATION_BUILD_DIR is the issue, then I think the problem is in CocoaPods using BUILT_PRODUCTS_DIR for copying the frameworks and forcing us to use CONFIGURATION_BUILD_DIR hack. If this is indeed the problem, we could make a small repro project and raise the issue with CocoaPods devs. — Reply to this email directly, view it on GitHub <#1885 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI54DTBXTSULAIBX5MUU653ZMOTKPAVCNFSM6AAAAABJLLNUQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBUHE3TQMA>. You are receiving this because you authored the thread.

[rh101]

Just an observation, when building a release version with debug info, then changing a single line of source code, the re-build issue never happened. It simply re-compiled the single file that was affected by the change, and then the final package. This was attempted multiple times, even with header file changes, where only the affected files referencing that header were re-compiled, and at no point did it rebuild the entire engine code etc..

The work-around of using the legacy build location wasn't used. This project is the same workspace that is having issues with the debug build, causing re-builds any time the project build or run command is used, even when there are no changes to the code.

[smilediver]

Wow, I can confirm that on my repro project. Switching to Release, MinSizeRel and RelWithDebInfo doesn't rebuild everything.

[smilediver]

So the reason why rebuild is triggered is because the response file containing common compiler options is rewritten. What triggers its rewrite only in debug builds I have no idea. An example bellow where I modify other.m file:

And another workaround seems to be to turn off "Use Response Files" build setting. Haven't tested on real project yet, but something like this should work:

set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CLANG_USE_RESPONSE_FILE No)

[rh101]

I just tried build with this:

set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CLANG_USE_RESPONSE_FILE No)

The rebuild still occurs, but not everything gets rebuilt, which is good, and this is all without any changes made to the project.

[asnagni]

Hi, I did some tests and don’t see the issue if I don’t use cocoapods. Are you experiencing the same thing? Thanks

…

On Jul 22, 2024, at 10:42 AM, smilediver ***@***.***> wrote: So the reason why rebuild is triggered is because the response file containing common compiler options is rewritten. What triggers its rewrite only in debug builds I have no idea. An example bellow where I modify other.m file: image.png (view on web) <https://github.com/user-attachments/assets/c9a14654-8034-4e47-898a-2c162906d7f0> And another workaround seems to be to turn off "Use Response Files" build setting. Haven't tested on real project yet, but something like this should work: set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CLANG_USE_RESPONSE_FILE No) — Reply to this email directly, view it on GitHub <#1885 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI54DTFT2UXAD32TBBRNWNLZNUK4DAVCNFSM6AAAAABJLLNUQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJRGU4DMMQ>. You are receiving this because you authored the thread.

[smilediver]

Hi, I did some tests and don’t see the issue if I don’t use cocoapods.

This has nothing to do with CocoaPods, I can reproduce this with a simple project without CocoaPods, see #1885 (reply in thread). It seems that rebuilding manifests only if you're building through Xcode workspace. If you build through Xcode project then everything is fine.

[asnagni]

Ok thank you for the clarifications. Stay safe

…

On Jul 23, 2024, at 10:25 AM, smilediver ***@***.***> wrote: Hi, I did some tests and don’t see the issue if I don’t use cocoapods. This has nothing to do with CocoaPods, I can reproduce this with a simple project without CocoaPods, see #1885 (reply in thread) <#1885 (reply in thread)>. It seems that rebuilding manifests only if you're building through Xcode workspace. If you build through Xcode project then everything is fine. — Reply to this email directly, view it on GitHub <#1885 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI54DTG5W6FIUPRT3Q43PETZNZRV7AVCNFSM6AAAAABJLLNUQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJSG42DKNQ>. You are receiving this because you authored the thread.

[AlexandreK38]

Hi! Jumping in this thread as I face the same issue, has anyone found a fix yet?

[AlexandreK38]

it seems to compile only what we need now with Use Responsive Files to No in the project (not target) and in the ax_libs sub project too. Targets inherit this value

[rh101]

What do you mean by "in the project (not target) and in the ax_libs sub project too"? Is this via the line:

set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CLANG_USE_RESPONSE_FILE No)

Or is it something you set via the Xcode UI, or a different line in cmake?

[AlexandreK38]

Yeah I set it using the Xcode UI but it should be the same as
set_target_properties(${APP_NAME} PROPERTIES XCODE_ATTRIBUTE_CLANG_USE_RESPONSE_FILE No)

As side note I didn't want to build the xcode project each time as the Cmakefile does, because with Cocoapods, Firebase, and few other tools have to be setup each time so I generate one Axmol project with subproject, extract the ax_libs.xcodeproj, tweak the links in it to be relative ones and use it in my main game xcodeproj, which is never regenerated. I always compile using Xcode

[rh101]

As side note I didn't want to build the xcode project each time as the Cmakefile does, because with Cocoapods, Firebase, and few other tools have to be setup each time

What do you mean by "setup each time"? The reason I ask is because how I have it set up is that axmol build **** is used to re-generate the xcode project, then I run pod install, and that's it. Everything is setup automatically, and this includes the Firebase cpp framework which isn't part of the Cocoapod setup. I've never had to setup anything manually in the Xcode IDE at all, if that's what you meant by "setup each time".

[AlexandreK38]

Even with Cocos2d before we used a subproject and do not build using the axmol commands; when we switched to Axmol I had a look to build like you do, with podfile and firebase it's ok, but I have some third party ruby scripts to run that modify the project and look at the pods too, it was a bit messy to make it work and run it each time after axmol build command. My CMakefile is more or less "ready" for axmol command but we don't use it and only use Xcode to build. I prefer this way and the axmol sources and ax_libs xcode project are in a common github submodule that we use for all our games.

[asnagni]

Hi AlexandreK38, As far as I remember, I don’t think there was a definitive solution to this issue but I may be wrong. But to avoid this issue we are using ccache, so we don’t think about it anymore. @rh101 would you have more information on this? I hope that helps.

…

On Oct 2, 2024, at 8:07 AM, AlexandreK38 ***@***.***> wrote: Hi! Jumping in this thread as I face the same issue, has anyone found a fix yet? — Reply to this email directly, view it on GitHub <#1885 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI54DTFGQYFACVGN7YANHN3ZZPOYJAVCNFSM6AAAAABJLLNUQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOBRHE4DSMA>. You are receiving this because you authored the thread.

[asnagni]

Hi AlexandreK38, We faced this issue when we first migrated to Axmol. After investigating we were not able to find the root cause so we implemented the ccache solution. Since, nobody is thinking about it since it is working perfectly for us now. Perhaps @rh101 may have some answers on that issue, you may want to ask him. Thank you, Stay safe

…

On Oct 2, 2024, at 9:39 AM, AlexandreK38 ***@***.***> wrote: smilediver's solution seems to improve, what I don't understand is why xcode compiles each file again though, including the axmol libs ones — Reply to this email directly, view it on GitHub <#1885 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI54DTG7XZAHB6TVQ4QPIBTZZPZR7AVCNFSM6AAAAABJLLNUQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOBSGA4TONY>. You are receiving this because you were mentioned.