Incremental build on iOS always considered dirty |
|||
Issue descriptionWhen doing an incremental build on iOS, the build does not stabilize (i.e. the next incremental build still tries to rebuild 6 targets): $ ninja -C out/Debug-iphonesimulator ninja: Entering directory `.../chromium/src/out/Debug-iphonesimulator' [6/6] STAMP obj/gn_all.stamp $ ninja -C out/Debug-iphonesimulator ninja: Entering directory `.../chromium/src/out/Debug-iphonesimulator' [1/6] CODE SIGNING //remoting/client/ios/app:ios_remoting_app(//build/toolchain/mac:ios_clang_x64) [2/6] STAMP obj/remoting/client/ios/app/ios_remoting_app.stamp [3/6] STAMP obj/remoting/client/ios/app/all.stamp [4/6] STAMP obj/remoting/client/ios/all.stamp [5/6] STAMP obj/remoting/remoting_all.stamp [6/6] STAMP obj/gn_all.stamp This is due to //remoting/client/app:ios_remoting_app target as "ninja -d explain" says: $ ninja -C out/Debug-iphonesimulator -d explain remoting/client/ios/app:ios_remoting_app ninja: Entering directory `.../chromium/src/out/Debug-iphonesimulator' ninja explain: output remoting-ios.app/remoting-ios doesn't exist ninja explain: remoting-ios.app/remoting-ios is dirty ninja explain: remoting-ios.app/_CodeSignature/CodeResources is dirty ninja explain: obj/remoting/client/ios/app/ios_remoting_app.stamp is dirty [0/2] CODE SIGNING //remoting/client/ios/app:ios_remoting_app(//build/toolchain/mac:ios_clang_x64)^C
,
Apr 20 2017
It looks like this is because the application bundle Info.plist sets CFBundleExecutable to chromoting. Since the script generating the bundle respect that Info.plist key (as it is technically possible that the binary is created with a different name before putting it in the application bundle). So either the bundle need to be renamed to chromoting.app or the CFBundleExecutable value should be changed to remoting-ios.
,
Apr 20 2017
,
Apr 20 2017
https://codereview.chromium.org/2827983005 for a fix.
,
Apr 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2c711f7b56b771b19f2c3d1a458815d0eeafe6df commit 2c711f7b56b771b19f2c3d1a458815d0eeafe6df Author: sdefresne <sdefresne@chromium.org> Date: Fri Apr 21 17:56:16 2017 [ios] Fix remoting application bundle. On iOS, the binary of an application bundle should be named after the application bundle without the .app suffix (see [1]). As the ios_app_bundle assumes this is the case but code_sign.py script respects CFExecutableName, both value need to agree. Fix the ios_remoting_app target by using the same value for the "output_name" variable and the "EXECUTABLE_NAME" expansion. [1]: https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1 BUG= 713668 Review-Url: https://codereview.chromium.org/2827983005 Cr-Commit-Position: refs/heads/master@{#466385} [modify] https://crrev.com/2c711f7b56b771b19f2c3d1a458815d0eeafe6df/remoting/client/ios/app/BUILD.gn
,
Apr 24 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by sdefresne@chromium.org
, Apr 20 2017Looks like the only binary in ios-remoting.app is a file named chromoting. According to the documentation [1], the application executable needs to have the same name as the application bundle minus the .app suffix: The executable file containing your application’s code. The name of this file is the same as your application name minus the .app extension. [1]: https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1