Problem
Pod lib lint passes with warnings about "no rules to process files" in the .xcodeproj/ folder of my framework.
Pod spec lint fails with the same warnings as above except also for MyLib/build. I don't have a MyLib/build folder in my repository. It also gives me 2 errors having to do with derived data.
error: Multiple commands produce '/Users/alex/Library/Developer/Xcode/DerivedData/App-efnsaqjhuzmwkkftkwknbhzigxxe/Build/Products/Release-iphonesimulator/MaterialFields/MaterialFields.framework/Headers/MaterialFields.h':
error: Multiple commands produce '/Users/alex/Library/Developer/Xcode/DerivedData/App-efnsaqjhuzmwkkftkwknbhzigxxe/Build/Products/Release-iphonesimulator/MaterialFields/MaterialFields.framework/Headers/MaterialFields-Swift.h':
What I've Tried
I've tried everything from deleting my derived data, erasing all my simulator content, cloning my repo into a different location and trying the commands again. I've checked my build phases for duplicate files. Nothing has worked.
I've opened up an issue on the cocoa pods GitHub (https://github.com/CocoaPods/CocoaPods/issues/8772). One of the contributors was kind enough to clone it and run it and it passed just fine (with the same 6 no rules to process warnings for stuff inside the .xcodeproj package).
My Thoughts
I'm expecting the linter to pass as it does locally. I have a feeling it has something to do with the MyLib/build file that gets created for the pod spec lint which gives me a lot of warnings. Likewise, I don't know how to fix the DerivedData error. I can't find any information to help me out online.
What files should I be excluding in my podspec? So far I'm only excluding the plist.
Related
So suddenly my project stopped working and I have no idea why and I'm running out of ideas.
I've found some blogs 1 2 and similar requests 1 2 3 for help but nothing seems to work for me. I may be doing something wrong though.
running xcode 13.4.1
I've got 4 distinct errors
Command EmitSwiftModule failed with a nonzero exit code
error: accessing build database "/Users/myuser/Library/Developer/Xcode/DerivedData/App-btdfdbatbdurmeawknwdwmjrqpsw/Build/Intermediates.noindex/XCBuildData/build.db": disk I/O error
Virtual filesystem overlay file '/Users/myuser/Library/Developer/Xcode/DerivedData/App-btdfdbatbdurmeawknwdwmjrqpsw/Build/Intermediates.noindex/App.build/Debug-iphoneos/App DEV.build/all-product-headers.yaml' not found
/Users/myuser/myapp-ios-app/App/UI/Feed/FeedVC/FeedVC.swift:11:8: No such module 'SDWebImage'
I believe the EmitSwiftModule is related with not being able to handle the pod therefore causing the issue in the "all-product-headers.yaml" which is generated to fetch all the pods headers?
So assuming that all things in derived date are as they should be (because i've deleted it) I tried to focus on why is the pod no longer compiling. To my co-worker is working fine. Maybe he will have the same issue if he deletes the derivedData? Maybe we are using some older version files?
Some things I've tried:
clean the project
reset pods cache
delete derived data folder
update the pods
clean xcode preferences
for this pod they say we should add :modular_headers => true in pod file
re download the project clean to another folder
instead of cocoapods use the package manager for SDWebImage
due "all-product-headers.yaml" issue i read here that i could just add a header to my project
I've tried to create a project from scratch and just use the same pods and the project seems to run fine. But this is not a solution.
Can someone please help me? Any ideas?
I tried a clean build, also disabled state cache. But still facing the issue.
Please help.
ERROR: autoconf-archive-native-2019.01.06-r0 do_populate_sysroot: The recipe autoconf-archive-native is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
/builds/mharriss/poky-tpm/build/tmp/sysroots/x86_64-linux/usr/share/aclocal/ax_check_enable_debug.m4
Matched in b'manifest-x86_64-gnome-common-native.populate_sysroot'
/builds/mharriss/poky-tpm/build/tmp/sysroots/x86_64-linux/usr/share/aclocal/ax_code_coverage.m4
Matched in b'manifest-x86_64-gnome-common-native.populate_sysroot'
Please verify which recipe should provide the above files.
The build has stopped as continuing in this scenario WILL break things, if not now, possibly in the future (we've seen builds fail several months later). If the system knew how to recover from this automatically it would however there are several different scenarios which can result in this and we don't know which one this is. It may be you have switched providers of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you need to execute the clean task for both recipes and it will resolve this error. It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those recipes should again resolve this error however switching DISTRO_FEATURES on an existing build directory is not supported, you should really clean out tmp and rebuild (reusing sstate should be safe). It could be the overlapping files detected are harmless in which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could also be your build is including two different conflicting versions of things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to resolve the conflict. If in doubt, please ask on the mailing list, sharing the error and filelist above.
ERROR: autoconf-archive-native-2019.01.06-r0 do_populate_sysroot: If the above message is too much, the simpler version is you're advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix things in most (but not all) cases.
ERROR: autoconf-archive-native-2019.01.06-r0 do_populate_sysroot: Function failed: sstate_task_postfunc
ERROR: Logfile of failure stored in: /builds/mharriss/poky-tpm/build/tmp/work/x86_64-linux/autoconf-archive-native/2019.01.06-r0/temp/log.do_populate_sysroot.5051
ERROR: Task (virtual:native:/builds/mharriss/poky-tpm/layers/meta-junos/recipes-devtools/autoconf-archive/autoconf-archive_2019.01.06.bb:do_populate_sysroot) failed with exit code '1'
I've been trying to get On-Demand Resource to work but I keep getting this compile error:
/* com.apple.actool.errors */
: error: The tag combination "tagName" for "xxx.imageset/xxx#3x.png" has no output specification.
I had a look at actool man page and there's an option:
--asset-pack-output-specifications filename
Which says:
Tells actool where to write the information about ODR resources found
in the asset catalog. The emitted file will be a plist.
But I'm not really sure what to put as an argument/where this plist is used or even if this option is in the right track of fixing the error.
My coworkers and I struggled with this error for over a day and were only able to fix it by wiping our existing local repos and installing a fresh clone from our remote repos with the code that contains the on-demand resources.
In our case, I was the one that created the on-demand resources functionality and did the tagging for the assets. I built and ran all of that code, and everything worked fine locally on my machine. I pushed those commits to our remote, and when my coworkers pulled they received the asset catalog compile error that you reported when they tried to build.
I compared my build logs with those of my coworkers and found that I had the --asset-pack-output-specifications flag along with a filename whereas they did not, even though all of our production code was the same. I never set that flag manually myself during development, it was automatically generated at some point in the process but I have no idea where -- I didn't even know it existed until this build failure occurred. After struggling for many hours we noticed that if my coworkers deleted their local projects entirely and basically started fresh by installing a new project and repo again from the remote, they suddenly were able to build. They had already tried to clean and nuke their derived data, but that didn't work. Only totally deleting the repos and the projects entirely did the trick. Not sure why, but something about wiping the project and all associated directories and building themselves totally fresh from their own local machines triggered something that enabled the --asset-pack-output-specifications flag.
I just faced this issue and was totally against deleting my repo and cloning again.
I noticed that alongside this error, I also got a warning stating that I had assets under the same name (thus being duplicated).
Deleting the duplicated asset in order to get rid of the warning, fixed the compilation error.
Hope this helps someone, as deleting the repo and cloning again shouldn't be an option.
I just faced the issue.
I could solve it just by deleting on-demand resource tags and tagging them back again.
I just solve it by rebooting Xcode then run successfully. The error seems to only appear once...I don't know why.
I'm trying to utilize the four Examples that ship with RestKit Version 0.20.1 Currently trying to Build RKSearchExample. The Build "succeeds" but no simulator appears and I get two warnings
1st one - Target Intergrity - The file "Pods-ios.xcconfig" couldn't be opened because there is no such file. ....
2nd one - Target Integrity - The file "Pods-ios.xcconfig" couldn't be opened because its path couldn't be resolved. It may be missing"
I assume that this file is missing and even though the Build succeeds with only warnings, it missing is causing the project to not actually complete its Build.
Does anyone have any idea where to find this file? Has one built the Examples included in RestKit successfully?
Thanks!
Came across same problem. Solved it by
Make sure .pch file is updated and missing frameworks are added to Build Phases (See 'Adding Frameworks to the Precompiled Header File' in https://github.com/RestKit/RestKit/wiki/Installing-RestKit-v0.20.x-via-CocoaPods)
Close the workspace, re-run '$ pod install' in the project directory,
Re-open the project (using .xcworkspace), do a Clean and Build.
Hey i had this same problem, I was getting the following error when running pod update however i didn’t realise the update wasn’t working.
$ pod update
Analyzing dependencies
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/pathname.rb:422:in `open': No such file or directory
It was because I forgot to run "pod setup" after installing cocoapods.
I ran pod setup from the terminal, followed it up with pod update (or pod install) and everything went to plan.
I am evaluating PostSharp for a new project but cannot seem to get past the following error when I first build the project after changes:
Cannot copy file "C:\SourcePath\Output\Debug\MyApp.vshost.exe to
obj\Debug\Before-PostSharp\MyApp.vshost.exe: the file is locked by
process(es):MYAPP.VSHOST (8064)
The error only occurs in the first build attempt. If I immediately re-build, the error does not occur. I can only guess this is because the project isn't actually being rebuilt the second time.
I've read a few posts in the SharpCrafters forum that indicate this problem existed prior to v2.1 but was reportedly fixed. I am using v2.1.6.14 from NuGet (in VS 2010) and getting this error for every project I reference PostSharp. It is certainly not reasonable to require 2 builds every time, so I'm looking for a possible solution. I'm really pleased with what I've seen thus far but will have to go another direction if that can't be resolved.
UPDATE
Per Gael's request, I generated the diagnostic build log and sent it to him and it looks like he was able to resolve the problem in the latest release (2.1.6.14).
I believe part (or all) of the issue may be due to the fact that the build output for all of my projects is set to a common location (i.e. not the /bin/debug folder under each project). This is because we are using a MEF DirectoryCatalog which will discover Imports and Exports contained in the assemblies located in the output path. The PostSharp.targets file has the vshost.exe file excluded from the copy operation but only when it shares the name of the output assembly. In my case, the vshost.exe file has a different name and was, therefore, not being excluded.
The issue has been re-fixed in PostSharp 2.1.6.15.