Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ios build fails with Pods and CONFIGURATION_BUILD_DIR configured #659

Closed
3 tasks done
Michael-Shemesh opened this issue Aug 20, 2019 · 10 comments · Fixed by #1310
Closed
3 tasks done

ios build fails with Pods and CONFIGURATION_BUILD_DIR configured #659

Michael-Shemesh opened this issue Aug 20, 2019 · 10 comments · Fixed by #1310
Milestone

Comments

@Michael-Shemesh
Copy link

Michael-Shemesh commented Aug 20, 2019

Bug Report

Running a cordova build on ios which uses pods with sub folders fails in PhaseScriptExecution [CP]\ Copy\ Pods\ Resources

Problem

Certain pods have an hierarchy which needs to be dynamically adjusted per pod via the CONFIGURATION_BUILD_DIR argument.
If this argument is already set then its value can't be overridden and the pods folder structure will no longer match the expected structure.

The following command is generated by cordova which causes the build to fail:
(notice the "CONFIGURATION_BUILD_DIR" argument)

xcodebuild -workspace HelloCordova.xcworkspace -scheme HelloCordova -configuration Release -destination generic/platform=iOS -archivePath HelloCordova.xcarchive archive CONFIGURATION_BUILD_DIR=/Users/michael.shemesh/dev/mobtest/cordova-hello-world/platforms/ios/build/device SHARED_PRECOMPS_DIR=/Users/michael.shemesh/dev/mobtest/cordova-hello-world/platforms/ios/build/sharedpch

Running the same without the "CONFIGURATION_BUILD_DIR" argument will make the build pass:

xcodebuild -workspace HelloCordova.xcworkspace -scheme HelloCordova -configuration Release -destination generic/platform=iOS -archivePath HelloCordova.xcarchive archive SHARED_PRECOMPS_DIR=/Users/michael.shemesh/dev/mobtest/cordova-hello-world/platforms/ios/build/sharedpch

What is expected to happen?

Allow to provide a parameter to disable setting the CONFIGURATION_BUILD_DIR argument.
(Setting it to empty also doesn't work since it is still counted by xcode as having a value)

The following is the code section which I wish to disable:
cordova/lib/build.js#L351

What does actually happen?

The ios build fails with the following error:

PhaseScriptExecution [CP]\ Copy\ Pods\ Resources /Users/<username>/Library/Developer/Xcode/DerivedData/Thryv-gfricshxsupkdfguznnnhnawnjkb/Build/Intermediates.noindex/ArchiveIntermediates/Thryv/IntermediateBuildFilesPath/Thryv.build/Release-iphoneos/Thryv.build/Script-201964EF33584F706397D9EB.sh
    cd /Users/<username>/dev/mobile-app-generator/build/platforms/ios
    /bin/sh -c /Users/<username>/Library/Developer/Xcode/DerivedData/Thryv-gfricshxsupkdfguznnnhnawnjkb/Build/Intermediates.noindex/ArchiveIntermediates/Thryv/IntermediateBuildFilesPath/Thryv.build/Release-iphoneos/Thryv.build/Script-201964EF33584F706397D9EB.sh
error: Resource "/Users/<username>/Library/Developer/Xcode/DerivedData/Thryv-gfricshxsupkdfguznnnhnawnjkb/Build/Intermediates.noindex/ArchiveIntermediates/Thryv/BuildProductsPath/Release-iphoneos/Braintree/Braintree-UI-Localization.bundle" not found. Run 'pod install' to update the copy resources script.

Information

Create a new cordova project, add the following to the config.xml file:

<plugin name="phonegap-plugin-push" spec="^2.2.3" />

Add the ios platform:

cordova platform add ios@5.0.1

Open the workspace in xcode and add code signing.

Build the project using cordova and see that it works:

cordova build ios --release --device

Add the following to your Podfile:

	pod 'Braintree', '~> 4.23.0'
	pod 'BraintreeDropIn'

Run pod install
Now try to build the project again and the error will be shown:

cordova build ios --release --device

Environment, Platform, Device

~/dev/cordova-hello-world » cordova -v
9.0.0 (cordova-lib@9.0.1)

~/dev/cordova-hello-world » pod env

Stack

   CocoaPods : 1.7.5
        Ruby : ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-darwin18.0]
    RubyGems : 3.0.4
        Host : Mac OS X 10.14.6 (18G87)
       Xcode : 10.3 (10G8)
         Git : git version 2.22.0
Ruby lib dir : /Users/michael.shemesh/.rvm/rubies/ruby-2.1.5/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ a4d0bc49a0346483284c63ecd0b9c31b2453ee14

Installation Source

Executable Path: /Users/michael.shemesh/.rvm/gems/ruby-2.1.5/bin/pod

Plugins

cocoapods-deintegrate : 1.0.4
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.1.0
cocoapods-trunk       : 1.3.1
cocoapods-try         : 1.1.0

Checklist

  • I searched for existing GitHub issues
  • I updated all Cordova tooling to most recent version
  • I included all the necessary information above
@ozgeekemen
Copy link

ozgeekemen commented Sep 18, 2019

Same problem with Google Tag Manager Pod.
<pod name="GoogleTagManager" spec="~> 7.0" />

ArcTanSusan pushed a commit to ArcTanSusan/cordova-ios that referenced this issue Sep 19, 2019
Use the user custom defined CONFIGURATION_BUILD_DIR as the default and if
undefined, then the value is an empty string.
@newdaveespionage
Copy link

newdaveespionage commented Sep 21, 2019

Also experiencing this with https://github.com/chemerisuk/cordova-plugin-firebase-inappmessaging even after forking and updating dependency version numbers. Pod asset is being fetched from the incorrect directory because of the CONFIGURATION_BUILD_DIR location.

This issue appears to be specific to builds on Xcode 10 and up using pods that have artifacts that need to be copied over during build, so the context of the values defining CONFIGURATION_BUILD_DIR are incorrect at the time the artifacts are called upon.

@jsheetzati
Copy link

Would also like to see the ability to disable setting CONFIGURATION_BUILD_DIR. I ended up forking cordova-ios and commenting out that line. Seems to work and not cause pod issues.

@CodeWithOz
Copy link

CodeWithOz commented Dec 17, 2019

@jsheetzati can you please post your env that worked after forking the repo and commenting out the line? I tried doing that but still couldn't get it to build. Here is my env:

My env:
Cordova cli: 8.1.2
Cordova ios: 5.1.1
Branch: 4.0.0
Pod: 1.8.4

@brodycj
Copy link
Contributor

brodycj commented Feb 17, 2020

I just added the help wanted label. It would be ideal if we can find a way to resolve this issue without breaking anything else. I would highly recommend people follow up with us on Slack or on the mailing list, follow links in the footer of cordova.io or cordova.apache.org.

@bobrosoft
Copy link

Same here with me BranchMetrics/cordova-ionic-phonegap-branch-deep-linking-attribution#633 😭😭😭

@EinfachHans
Copy link

any plans on this?

@seamlink-aalves
Copy link

Hi,

I'm also experiencing this issue. Anyone found a solution?

@bobrosoft
Copy link

@seamlink-aalves in result I forked the repo, committed a fix for it and using my fork in packages.json as

"branch-cordova-sdk": "git://github.com/bobrosoft/cordova-ionic-phonegap-branch-deep-linking-attribution.git",

@seamlink-aalves
Copy link

Any chance of having the #671 merged for the next big update? This is currently blocking us from building our apps throught command line interface and enabling build automation?

cmfsotelo added a commit to OutSystems/cordova-ios that referenced this issue Nov 25, 2022
cmfsotelo added a commit to OutSystems/cordova-ios that referenced this issue Nov 25, 2022
cmfsotelo added a commit to OutSystems/cordova-ios that referenced this issue Nov 28, 2022
dpogue added a commit to dpogue/cordova-ios that referenced this issue Apr 15, 2023
Once upon a time, Xcode's default directory values had issues when there
were spaces in project names, so we override the CONFIGURATION_BUILD_DIR
and SHARED_PRECOMPS_DIR variables with our own paths.

However, this can interfere with Cocoapods, and Xcode should be able to
handle things sensibly nowadays.

Closes apache#659.

Co-Authored-By: Susan Tan <susan@getwellio.com>
@dpogue dpogue added this to the 7.0.0 milestone Apr 15, 2023
dpogue added a commit to dpogue/cordova-ios that referenced this issue Apr 16, 2023
Once upon a time, Xcode's default directory values had issues when there
were spaces in project names, so we override the CONFIGURATION_BUILD_DIR
and SHARED_PRECOMPS_DIR variables with our own paths.

However, this can interfere with Cocoapods, and Xcode should be able to
handle things sensibly nowadays.

Unfortunately, that results in our build artifacts living somewhere in a
randomly-named Xcode DerivedData directory, and then we can't do things
like run the app in a simulator or on a device because we don't know the
path to it.

Setting SYMROOT allows us to control the output directory of the built
products, with the caveat that Xcode always creates a subdirectory named
with the current configuration.

So instead of `build/emulator`, we'll have `build/Debug-iphonesimulator`
and instead of `build/device`, we'll have `build/Release-iphoneos`.

Hypothetically this is better because now we are sure that debug and
release files never get mixed up in the same output directory.

The downside is that this is a breaking change because it alters the
path for the output .ipa files.

Closes apache#617.
Closes apache#659.
Closes apache#671.

Co-Authored-By: Susan Tan <onceuponatimeforever@gmail.com>
dpogue added a commit to dpogue/cordova-ios that referenced this issue Apr 16, 2023
Once upon a time, Xcode's default directory values had issues when there
were spaces in project names, so we override the CONFIGURATION_BUILD_DIR
and SHARED_PRECOMPS_DIR variables with our own paths.

However, this can interfere with Cocoapods, and Xcode should be able to
handle things sensibly nowadays.

Unfortunately, that results in our build artifacts living somewhere in a
randomly-named Xcode DerivedData directory, and then we can't do things
like run the app in a simulator or on a device because we don't know the
path to it.

Setting SYMROOT allows us to control the output directory of the built
products, with the caveat that Xcode always creates a subdirectory named
with the current configuration.

So instead of `build/emulator`, we'll have `build/Debug-iphonesimulator`
and instead of `build/device`, we'll have `build/Release-iphoneos`.

Hypothetically this is better because now we are sure that debug and
release files never get mixed up in the same output directory.

The downside is that this is a breaking change because it alters the
path for the output .ipa files.

Closes apache#617.
Closes apache#659.
Closes apache#671.

Co-Authored-By: Susan Tan <onceuponatimeforever@gmail.com>
dpogue added a commit to dpogue/cordova-ios that referenced this issue Apr 16, 2023
Once upon a time, Xcode's default directory values had issues when there
were spaces in project names, so we override the CONFIGURATION_BUILD_DIR
and SHARED_PRECOMPS_DIR variables with our own paths.

However, this can interfere with Cocoapods, and Xcode should be able to
handle things sensibly nowadays.

Unfortunately, that results in our build artifacts living somewhere in a
randomly-named Xcode DerivedData directory, and then we can't do things
like run the app in a simulator or on a device because we don't know the
path to it.

Setting SYMROOT allows us to control the output directory of the built
products, with the caveat that Xcode always creates a subdirectory named
with the current configuration.

So instead of `build/emulator`, we'll have `build/Debug-iphonesimulator`
and instead of `build/device`, we'll have `build/Release-iphoneos`.

Hypothetically this is better because now we are sure that debug and
release files never get mixed up in the same output directory.

The downside is that this is a breaking change because it alters the
path for the output .ipa files.

Closes apache#617.
Closes apache#659.
Closes apache#671.

Co-Authored-By: Susan Tan <onceuponatimeforever@gmail.com>
dpogue added a commit to dpogue/cordova-ios that referenced this issue Apr 16, 2023
Once upon a time, Xcode's default directory values had issues when there
were spaces in project names, so we override the CONFIGURATION_BUILD_DIR
and SHARED_PRECOMPS_DIR variables with our own paths.

However, this can interfere with Cocoapods, and Xcode should be able to
handle things sensibly nowadays.

Unfortunately, that results in our build artifacts living somewhere in a
randomly-named Xcode DerivedData directory, and then we can't do things
like run the app in a simulator or on a device because we don't know the
path to it.

Setting SYMROOT allows us to control the output directory of the built
products, with the caveat that Xcode always creates a subdirectory named
with the current configuration.

So instead of `build/emulator`, we'll have `build/Debug-iphonesimulator`
and instead of `build/device`, we'll have `build/Release-iphoneos`.

Hypothetically this is better because now we are sure that debug and
release files never get mixed up in the same output directory.

The downside is that this is a breaking change because it alters the
path for the output .ipa files.

Closes apache#617.
Closes apache#659.
Closes apache#671.

Co-Authored-By: Susan Tan <onceuponatimeforever@gmail.com>
erisu pushed a commit that referenced this issue May 28, 2023
Once upon a time, Xcode's default directory values had issues when there
were spaces in project names, so we override the CONFIGURATION_BUILD_DIR
and SHARED_PRECOMPS_DIR variables with our own paths.

However, this can interfere with Cocoapods, and Xcode should be able to
handle things sensibly nowadays.

Unfortunately, that results in our build artifacts living somewhere in a
randomly-named Xcode DerivedData directory, and then we can't do things
like run the app in a simulator or on a device because we don't know the
path to it.

Setting SYMROOT allows us to control the output directory of the built
products, with the caveat that Xcode always creates a subdirectory named
with the current configuration.

So instead of `build/emulator`, we'll have `build/Debug-iphonesimulator`
and instead of `build/device`, we'll have `build/Release-iphoneos`.

Hypothetically this is better because now we are sure that debug and
release files never get mixed up in the same output directory.

The downside is that this is a breaking change because it alters the
path for the output .ipa files.

Closes #617
Closes #659
Closes #671

Co-authored-by: Susan Tan <onceuponatimeforever@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants