From where CopySwiftLibs gets executed? I am trying to avoid getting libswift*.dylib which gets copied through CopySwiftLibs, I see an option in xcode, which is "Always Embed Swift Standard Libraries", but it is set to "No", but still libswift libraries gets copied to Contents/Frameworks/ of app. Is there a way yo avoid it?
CopySwiftLibs phase calls swift-stdlib-tool. You can learn about its usage with this Terminal command:
xcrun swift-stdlib-tool --help
There’s an option called --source-libraries <path> that defines where to copy the libraries from. Apparently, to prevent it from copying any libraries you can set that path to some empty or non-existent folder.
You can define custom OTHER_SWIFT_STDLIB_TOOL_FLAGS build setting for your target and set it to
--source-libraries /dev/null
Related
I want to add a Run Script Phase to my Build Phases to call a swift executable that takes a plist file from my project and uses it to generate a swift file with some boilerplate code.
I figured out how to specify the input file for the Run Script Phase like this:
$(SRCROOT)/MyProject/MyData.plist
But for output files, Xcode gives me this $(DERIVED_FILE_DIR)/newOutputFile default value which, if I echo it via echo "$SCRIPT_OUTPUT_FILE_0", prints some strange path to the ....MyProject.build/DerivedSources folder. What is that? What do I do with this and how can I generate my output swift file and place it inside my project?
I don't really find much information about this $(DERIVED_FILE_DIR) (at least nothing that I understand, I've never worked with these things before).
Thanks!
Presumably the derived file directory is just a safe place to write output results to. It isn't in the project directory, but it is unique to the project.
However, you do want to write directly into the project directory (I presume), so just go ahead and do so, using the environmental variable PROJECT_DIR.
When I compile my swift framework MyFramework I makes so that Xcode produces MyFramework.framework (the compiled framework) and MyFramework.framework.dSYM (the dSYM file).
By running dwarfdump myframework.framework.dSYM/Contents/Resources/DWARF/MyFramework I've noticed that all the paths to the source files are absolute paths.
This makes it impossible to share these two artefacts (together with the source code) with my colleagues and allow them to use the compiled framework and being able to debug their code properly. More precisely they are not able to step-in inside the framework with the debugger.
For this reason they need recompile the framework which is very inconvenient.
Is there a way to modify the DWARF to edit these paths or even better to convince Xcode to use relative path in the DWARF file?
While I'm not aware of a way to change the paths stored in the dSYM or to make them relative, I can offer a way to work around the issue and be able to debug with those symbols on an arbitrary machine with source code in a different base path.
Once you find out what the original path is (e.g. /Users/rob/src/Project), and you have the code for that library in e.g. /Users/luka/Sources/Project, then you can issue this lldb command, which will replace for that session of the debugger the original path with your path:
settings set target.source-map /Users/rob/src/Project /Users/luka/Sources/Project
Unfortunately you'll need to run this command for each debugging session. To do that, you can create a breakpoint in your main, which runs that command and continues execution without stopping.
To find the original source path you can either use dwarfdump as you mention, or you can look up a symbol you know is in that binary from lldb with im loo -v -n MySymbol or through other parameters of the command (depending on the type of symbol you're trying to use).
I'm working with some third party tools that generate xcode project files for a few subcomponents. Their tools generate the project files with Generate Position-Dependent Code set to YES (potentially because the tool generates project files for OS X builds too and the latest update has it confused).
While I could simply turn these flags off in the GUI, it's not as convenient as my build process is scripted to generate each project file, build it, move binaries around, lipo them together, etc.
I'm fairly sure these settings can be overridden on the command line, but I'm curious as to what the setting key actually is. For instance, I don't know if the setting=value means that the setting name is verbatim to how it displays in Xcode (Generate Position-Dependent Code), as there are spaces in it.
If anyone can provide a listing of all settings that can be passed to xcodebuild, that would be super.
The setting name is actually GCC_DYNAMIC_NO_PIC. "Generate Position-Dependent Code" is just the description.
For future reference, when I copy (Command+C) that setting when it is highlighted in project Build Settings...
...then paste into Text Edit I see the actual command line setting key.
//:configuration = Debug
//:configuration = Release
//:completeSettings = some
GCC_DYNAMIC_NO_PIC
That works for all build settings, too.
May I use a settings bundle in xcode which is not called Settings.bundle?
If I have multiple settings bundles (for multiple build targets), must I define these additional names anywhere? My application seems to always look for one called Settings.bundle.
For those of you who aren't good at shell scripts, here's a template version of what I used. In addition to a Debug and Release build, we also had a Debug-Special build with its own Info.plist in the build settings, and a different Settings.bundle/Root.plist file. I created copies of the Setting.bundle/ folder to Settings(original).bundle and Settings(special).bundle and added this script to the pre-build:
subdir="original" ; [[ $CONFIGURATION = "Debug-Special" ]] && subdir="special" ; cp "$SRCROOT/Settings($subdir).bundle/Root.plist" "$SRCROOT/Settings.bundle/"
Be sure to select your project to add the environment variables to the shell that runs the script.
I realize the thread is pretty old in code years but it is still relevant, and hopefully this will save the next person who finds it some time.
Solved this by adding a script in pre-build where the alternative bundle is renamed to Settings.bundle
How do I build Borland C++ project files (bpr) and package files (bpk) from the command line? Project groups (bpg) are apparently make files and can be compile with make. But bpks and bprs are xml based and the Export to Makefile won't compile with make.
If I put a project in a bpg, make can't seem to find any of the files specified in the bpg since they all appear to be relative references. I changed the references to absolutes and make reports:
Fatal: Unable to open makefile
You don't need to directly compile a bpr. Just create a bpk which just includes that single bpr, and you can use make to compile it.
"c:\program files\borland\cbuilder5\bin\make" -B -s -fabc.bpg
If you also have other borland compilers installed, do not call the make.exe from the other compiler.
EDIT: execute the make command in the directory where the bpg and bpr is located.
Using bpr2mak and make works for me just fine, so as Roger said, you need to give details on what errors you're getting. BPK files can also be processed with bpr2mak. I'm using this method to compile a large project with many components, without difficulties.
Perhaps you could give some more information on 'won't compile'.
I.e. What error messages are you getting.
One frequent problem the come up with make is addressed at the following
http://www.delphigroups.info/3/8/36427.html