Here is the situation I have:
ProjectA - Xcode static library project.
ProjectA contains logical code group ExternLib with file ExternLib.h. ExternLib.h itself is in the folder Classes/lib/ExternLib (relative to ProjectA folder). Within ProjectA, I use ExternLib.h simply as: #import "ExternLib.h". This works fine.
Next I have ProjectB. This includes ProjectA as a linked Xcode project. The target has been added correctly etc. However, when I include a file in ProjectB which in turn includes ExternLib.h, upon building ProjectB, I get an error saying that the file ExternLib.h cannot be found.
I have tried adding the path to ExternLib.h to the header search path (all types: relative, absolute, with recursion etc.) but to no avail. I have checked that static library target has the copy headers step and the file ExternLib.h is included in it.
Anybody able to shed some light on how to get around this?
Add a Run Script Build Phase to the target for ExternLib that executes
mkdir -p "${BUILT_PRODUCTS_DIR}ExternLibHeaders"
Add a Copy Files build phase that copies the ExternLib header files into ${BUILT_PRODUCTS_DIR}ExternLibHeaders, and add all of ExternLib's headers into that phase.
In the app target for ProjectB, add ${BUILT_PRODUCTS_DIR}/ExternLibHeaders/ to the Header Search Paths for all configurations.
In Xcode > Preferences > Build, set the Build Products Directory to some common location.
The fourth step is crucial; it ensures that BUILT_PRODUCTS_DIR is the same for both projects.
It's really hard to say what might have gone wrong.
I'd start from scratch with a tutorial on building and using static libraries, and see if any of the steps jog any ideas out of you.
Related
I'm trying to set up Xcode to build generated .c files just like it does for files generated by yacc (*.y) and lex (*.l) files.
Say I have input files with a *.corn extension that are meant to be processed by a tool of mine to create C source files. I then want these C source files to be compiled and linked using the rest of Xcode's mechanisms.
This is exactly what happens to my .y and .l files for yacc and lex. The project target contains only the .y and .l files and the rest happens automatically. Generated .c files get put in the derived files directory and those get compiled and linked automatically.
Here's what I've tried so far:
-If I just add a .corn file to my target, Xcode copies it into the bundle at build time presuming it is a resource. Okay, whatever.
-I then create a custom build rule to handle
Source files with names matching: *.corn
Using Custom Script:
#!/bin/sh
cp "${INPUT_FILE_PATH}" "${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}.c"
I have to give it an output file so:
OutputFiles:
${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}.c
Note in this case I'm just copying the file as I rename it with .c extension. (As I'm playing around, the .corn file just contains C source.)
So now before the bundle directory even gets created I get the following warning:
unexpected C compiler invocation with specified outputs: 'blahblahblah/Build/Products/Debug-iphonesimulator/MyApp.app/foo.c' (for input: 'blahblahblah/Build/Intermediates.noindex/MyApp.build/Debug-iphonesimulator/MyApp.build/DerivedSources/foo.c')
Then after the link phase (sheesh!), the script above runs and I do end up with my foo.c in DERIVED_FILES_DIR. It doesn't get compiled however and notably, foo.corn didn't get copied into the bundle anymore so there's hope.
I've tried a bunch of other stuff, but this is the cleanest I can describe that others can try. Please what is the magic incantation to make this work?!
Note that I've also tried using DERIVED_SOURCES_DIR instead of DERIVED_FILES_DIR.
So I missed two things:
I needed to add the .corn files to the "Compile Sources" build phase.
By adding .corn files to the project/target before the adding the custom build rule, Xcode added the .corn files to the "Copy Bundle Resources" build phase which broke the build.
Our iOS app currently is using Google protobuffer gRPC as our API layer to communicate between App and backend. And so we have these .proto files in our backend directory which will be converting to .grpc.swift and .pb.swift files by gRPC-Swift-Plugins and then consumed by the App.
This works okay, but the process of converting is very tedious, and we would like to automate the whole process.
Below is how we're doing it:
Delete previously copied directory, and copy all .proto files from backend (.proto files are maintained by backend devs) to App directory named "Protos" via a shell script
We already set up Build rules and include .proto files in Compile Sources. Following the steps from an answer here on SO
Screenshot of the current setup in Xcode Build Rules:
Whenever we build the project, .pb.swift and .grpc.swift are generated and putting into a directory named "generated" under the "Protos" folder.
Here are the problems:
If the backend added a new .proto files into the source directory, my script will only copy the files into the Protos directory but not included news files in the Compile Sources list.
Similar to the first problem, we need to manually set up Compile Sources in Xcode and that means if a new dev joins our team, he/she also needs to do the same setup again.
We sometimes need to refer to the .grpc.swift and .ph.swift files while coding. But If we add these files into Xcode and build the project again, Xcode will complain that these generated files are there like (Sorry, we're working on a private repo, so the project name and file names are replaced):
Multiple commands produce '${user_path}/${proto_name}.pb.o':
Target '${my_project_name}' (project '${my_project_name}') has compile command for Swift source files
Target '${my_project_name}' (project '${my_project_name}') has compile command for Swift source files
Any answers or comments and suggestions are greatly appreciated!
It's interesting I didn't have those problems with Swift if I use the $DERIVED_FILE_DIR
protoc "$INPUT_FILE_NAME" --swift_out="$DERIVED_FILE_DIR" --proto_path="Your/proto/path"
I don't use the plugin because I've got the plugin installed in my /usr/local/bin
But I have exactly those problems when we use the output for cpp files.
On Xcode 11 my .xcassets, that don't cause any issue on Xcode 10, cause the compilation to fail with the following message:
error: Multiple commands produce '/Users/user/Library/Developer/Xcode/DerivedData/project-enjiypsgxtcdbnaripixgtnjlagx/Build/Products/Debug-iphonesimulator/project.app/Assets.car':
1) Target 'project' (project 'project') has compile command with input '/Users/user/sandbox/project/Resources/buttons.xcassets'
2) That command depends on command in Target 'project' (project 'project'): script phase “[CP] Copy Pods Resources”
The only way I'm able to compile the project is by removing the .xcassets from the target with the obvious downside of having them not available on the build.
PS: This is happening for 2 ObjC projects.
Add below line at the top of your pod file, right after platform :ios
install! 'cocoapods', :disable_input_output_paths => true
Reference
The answer above is only partially correct: yes, this happens because the pod phase produces Assets.car as an output file, which coincides with the output name for your xcassets - hence Multiple commands produce... error: one command being the script phase [CP] Copy Pods Resources and another - your own project's compile command.
But removing Assets.car from output files will cause the build system to fail to see that the script processes the file, thus it skips it (read this for more details). So what we can do is add Assets.car to the input files - this will create a dependency for the script, telling the build system to wait for the file before executing the script.
NB: like the solution above, you will have to do this every time after updating your pods, since [CP] Copy Pods Resources is generated every time you run pod install or pod update
To be sure that all build steps are performed in the correct order, yet as many steps in parallel as possible, Xcode needs to know for every build step which input files it depends on and which output files it will generate.
E.g. if step A depends on an input file that is the output file of step B, step B surely has to run before step A. If neither step requires the output file of the other step, they can both run in parallel.
While several steps can surely depend on the same input file, it cannot be the case that multiple steps produce the same output file as in that case, whichever step runs last would overwrite the output file of whichever step runs first and this means the resulting output file content would be unpredictable and that is an error in a build process that shall created predictable results!
In your case the problem is that your Copy Resources build phase contains one (or more) .xcassets bundle(s). Xcode won't just copy these bundles, instead it will combine them, convert and optimize their content, and create a file called Assets.car that contains the content of all the assets catalogs in your project.
Yet if you integrate a Pod and this Pod also has an asset catalog, exactly the same thing will happen and a second Assets.car file is created and now Xcode has a problem: Two build steps both say they create an Assets.car file. Which one shall win? Which of these two files shall end up in the final application? And what about other steps that depend on this file? After which of the build steps do they have to run? This is a serious problem that Xcode cannot resolve.
There are currently two possibly solutions:
Use frameworks. When you use frameworks instead of static libraries, the resources of Pods don't end up in the resources folder of your main application but in the resources folder of the built framework. All you need to do is to add use_frameworks! to your Podfile, either top level or just for a specific target. The downside is that your overall app size will grow a bit and app start time will increase a bit.
Have the Pod-author fix the Pod. Instead of resources s/he shall use resources_bundle as the Podspec documentation also strongly recommends. Using resources actually has other disadvantages (resource files are not optimized, name conflicts can arise between different Pods), whereas using a resource bundle is safe, regardless if Pods are embedded as static libraries or as dynamic frameworks. Note, though, that it is not enough to just alter the Podspec, all code that loads bundle resources must be adopted to load them from the correct bundle (the name will be known as when using resources_bundle in a Podspec file, you also must give the bundle(s) a name).
There is an on-going bug report for this issue, you can find it here:
https://github.com/CocoaPods/CocoaPods/issues/8122
Yet the problem currently is, that every possible solution other than the two mentioned above would basically be an ugly hack and the Cocoapods developers are not happy implementing ugly hacks. The best solution, as hard as it seems, is probably to not fix that problem at all but to stop supporting resources in Podspec files and make resources_bundle mandatory for Pods that contain own resources.
In your library project, such as "LADetailPage", open Targets' "Build Phases", create a predefined phase named "Copy Files", then drag your *.xcassets to the new phase.
Then the library won't make Assets.car from *.xcassets files when building, instead, cocoapods copies the *.xcassets to your main project which imports the lib, and the main project builds all *.xcassets into a single Assets.car file.
Please check your dependencies if there is some pods use 'resources'(not 'resources_bundle') to link its own xcassets in podspec.
This way has beed deprecated, because its output file name is 'Assets.car'. It is same with your project xcassets' compile output name.
Xcode->File->Workspace settings->Building System-> Legacy Build System
example
I have a sub project that has been developed as dynamic lib and included that sub project into my main project and been set as target dependency.
When I run my main project, .a file for my sub project has been created successfully and the corresponding header files are created in the build directory such as (build/release-iphoneos/include). I have mentioned path using MACRO
In my main project, I mentioned header search path as the same that i mentioned above using MACRO.
But when I try to archive the build it throws the run time error file not found in the import statement
#import <subproject/myfile.h>
But it is getting build and run successfully even though it displays the file not found error in the xcode editor in compile time.
My question is
Is this because of the build directory will be empty while archieving?
I solved the problem as below
1. The header files were private so changed them as public so they are exposed to main project. (To build & run successfully)
2. I copied the header files and created a directory and add them into my main project and set the header search path to point that directory (To archive successfully)
I have 2 projects, which build one static library each, as well as another project which uses both static libraries.
One of the two static libraries builds fine. The other one does not and the reason for that is that its public headers are not copied to the build folder before the custom shell script runs.
Here is a demonstration of what happens:
SampleA (the one that works)
Compile MyClass1.cpp ...
Compile MyClass2.cpp ...
Libtool /Users/user/Library/Developer/XCode/DerivedData/.....
Libtool /Users/user/Library/Developer/XCode/DerivedData/.....
Libtool /Users/user/Library/Developer/XCode/DerivedData/.....
Create universal binary libSampleA.a ...
Copy SampleA.h ...in /Users/user/....
Copy MyClass1.h ...in /Users/user/....
Copy MyClass2.h ...in /Users/user/....
Run custom shell script 'Prepare Framework'
Stripping libSampleA.a
--- Build complete
SampleB (the one that does NOT work)
Compile OtherClass1.cpp ...
Compile OtherClass2.cpp ...
Libtool /Users/user/Library/Developer/XCode/DerivedData/.....
Libtool /Users/user/Library/Developer/XCode/DerivedData/.....
Libtool /Users/user/Library/Developer/XCode/DerivedData/.....
Create universal binary libSampleB.a ...
// >>>>> NO HEADER FILES ARE COPIED <<<<<<
Run custom shell script 'Prepare Framework'
--- Build fails (header folder does not exist)
My current setup is a workspace that includes all 3 projects, but I used to have 1 project with one nested project for each static library as well. The issue I have remains the same in both setups.
More info
I have tried virtually every instruction, tip and advice I found online for making this work.
The settings on both projects, as far as I can tell, are identical. Comparing the two project files wasn't very effective. I also haven't compared all the settings of both projects one by one to make sure they are the same (yet).
The problem is the same in both Debug and Archive builds (I know that archiving behaves differently)
I have added "$(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts/include" and/or "$(PROJECT_TEMP_DIR)/../UninstalledProducts/include"
I have added the headers to the "Build Phases > Copy Headers > Public" section - didn't work
I have deleted the "Build Phases > Copy Headers" phase completely, as Apple suggest and added the headers to the Copy Files phase - didn't work
I have added a new group in the static lib project and added all its headers, setting no target to "Add to Targets" - didn't work
I have quit XCode and tried again, or even restart the mac - didn't work
One difference between the two libraries is that SampleB (the one that does not build) includes various headers from SampleA. There are no compiler or linker errors, just the error at the end of the build that I describe.
Sources
Some of the sources I have used for the creation of the library, as well as for trying to solve the issue:
https://developer.apple.com/library/ios/technotes/iOSStaticLibraries/Articles/creating.html
Xcode 4 can't locate public header files from static library dependency
Compile, Build or Archive problems with Xcode 4 (and dependencies)
http://www.blog.montgomerie.net/easy-xcode-static-library-subprojects-and-submodules
So, do you know what triggers the headers to be copied or not be copied, during the build?
I would suspect that even if one header file is added to the Copy Headers phase or the Copy Files phase, at least this should be copied. But as it turns out, this is not what happens, at least in my case.
Following Apple's instructions, and just creating a CocoaTouch static library project from the template:
Ensure you have placed your custom "Run Script" phase after the "Copy Files" phase:
Then, when building, the transcript will look as this:
In my setup I have a parent project with a nested project, which emits a static library.
I tried with a Headers phase, I couldn't get Xcode to copy the headers in the right spot when archiving. Plus the headers and the static library were copied into the archive, which you don't want. So I ended up using a Copy Files phase and setting Skip Install to YES while pointing the Header Search Paths in tha parent project to BUILT_PRODUCTS_DIR.