-
Notifications
You must be signed in to change notification settings - Fork 984
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
Comments
Same problem with Google Tag Manager Pod. |
Use the user custom defined CONFIGURATION_BUILD_DIR as the default and if undefined, then the value is an empty string.
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 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 |
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. |
@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: |
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. |
Same here with me BranchMetrics/cordova-ionic-phonegap-branch-deep-linking-attribution#633 😭😭😭 |
any plans on this? |
Hi, I'm also experiencing this issue. Anyone found a solution? |
@seamlink-aalves in result I forked the repo, committed a fix for it and using my fork in packages.json as
|
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? |
this aims to fix apache#659
this aims to fix apache#659 and apache#617
this aims to fix apache#659 and apache#617
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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)
Running the same without the "CONFIGURATION_BUILD_DIR" argument will make the build pass:
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:
Information
Create a new cordova project, add the following to the
config.xml
file:Add the ios platform:
Open the workspace in xcode and add code signing.
Build the project using cordova and see that it works:
Add the following to your Podfile:
Run
pod install
Now try to build the project again and the error will be shown:
Environment, Platform, Device
~/dev/cordova-hello-world » cordova -v
9.0.0 ([email protected])
~/dev/cordova-hello-world » pod env
Stack
Installation Source
Plugins
Checklist
The text was updated successfully, but these errors were encountered: