It looks like xcode's $PATH environment setting is different from my user shell environment.
Where does xcode get the $PATH setting from and what's the best way to append to the search path?
if you're writing a Run Shell Script build phase, you can just do:
PATH=${PATH}:/opt/local/bin
or whatever inside the script content.
There's some confusion in these answers, as some of them are trying to solve the $PATH for the built executable being run by Xcode. But the question is about Xcode, implying that it's about the build process itself.
For example, in a Build Phase Run Script step that runs an executable installed by Homebrew. It's not a good idea to hard-code the build process to include a path that is specific to one build machine (New macOS versions come out, new developers join the team, etc.)
The problem has multiple layers:
Changing $PATH in bashrc/zshrc/profile takes effect on shell sessions, but not in macOS applications
To solve this, you can set the PATH for applications using:
sudo launchctl config user path $PATH
You will then need to restart your machine for the change to take effect. You will need to run this again if you change your $PATH.
(This came from a comment on GitHub.)
Xcode by default does not use the system $PATH, and replaces it with its own sanitized value
This is solved by changing a User Default. This probably has some risk, since Xcode does this sanitization to ensure that its own build tools are used, and if you have executables with the same name in other places, they might be run instead. Caveat emptor!
defaults write com.apple.dt.Xcode UseSanitizedBuildSystemEnvironment -bool NO
And it looks like this gets reset on every restart of macOS, so be prepared to issue this command every time you restart.
(This part came from this answer.)
The easiest solution is to add the PATH variable in Xcode.
PATH=${PATH}:/usr/local/bin
This applies for OSX 10.7 and earlier ONLY.
XCode gets its environment variables the same way as other OS X processes, from ~/.MacOSX/environment.plist.
Check developer.apple.com/qa/qa2001/qa1067.html for details on how to set things.
In Xcode 5 you can add your PATH as a variable to either a target or the project settings.
Add a custom variable with the +sign on the top of the page
Edit the name of the variable to be PATH and add your preferred value (e.g. /usr/local/bin for a default install of homebrew.
If you are talking specifically about the executable search path environment variable named PATH, then there are a few places that it is set:
In your shell settings if it is a command line tool. Depending on your shell, this could be ~/.cshrc, ~/.profile, ~/.bash_profile, etc.
In the environment.plist file that was mentioned earlier.
If you are in a debugger, then it is whatever gdb uses. I believe that gdb will read commands from ~/.gdbinit if it exists.
XCode lets you set environment variables within the Info page for executables.
This is an update for later versions of macOS and Xcode as things have altered. This is with Xcode 11.0 and macOS 10.14
The biggest issue is that ~/.MacOSX/environment.plist does not get read now.
Build Settings
This means that if in the build you need the PATH set, e.g. for external builds and they run executables there is no simple solution. /etc/paths does not seem to be read either.
The solution is as in #GhostLyrics answer to add the PATH variable in Build Settings. However as noted in comments Xcode will not just use that value but it puts its own values before that. Also it does a straight textual substitution and so you need to also add the separator that PATH uses i.e. the : (colon). The value I have added is :opt/local/bin I also found that you can only do this for a target and not at the project level.
Run Shell Script
This is the simple case as in this answer
PATH=${PATH}:/opt/local/bin
or whatever inside the script content.
Alternatively put this change in your non login shell starter file e.g. ~/.bashrc ~/.zshrc
Running the executable
This is done in the Schema in the Run portion.
Set PATH in the environment variables as stated in answers here. Note I have not tried this and I am not certain how much of the PATH needs setting.
Xcode doesn't look at your shell path environment.
Have a look at NSProcessInfo; and do an NSLog to see what comes up.
If you want a path to apply to all graphical programs you need to set up the ~/.MacOSX/environment.plist. as described.
The recommended way to set the environmen variables are actually in /etc/paths and etc/paths.d although these are also not picked up by Xcode.
I asked about this here.
Nothing was working for me in XCode 7.
You need to set the PATH variable in XCode schemes.
Found the solution at:
Where to set environment variables for app?
Try opening your xcode project from the terminal, this worked for me: open some.xcodeproj
Instead of opening xcode and then loading the project or double clicking on it.
I know... silly
Related
So I'm following the install instructions for Bazel 2.0, and basically it seems like all I have to do is download the ".exe" file, add it to the path, and then I can use it from windows powershell (probably bash too, although I haven't tried). What I want to know is - does the ".exe" file do any manipulation of my system (outside of the obvious compiling work) or download anything else under the hood? I ask because I want to try it out while working on a restricted computer system, as I'm sure some of you have encountered before.
It will extract itself into the location where it also (unless configured otherwise) keeps its build output. By default this would be under current user's home directory. The location can be changed with --output_user_root parameter or TEST_TMPDIR environmental variable. You can check out the docs for more detailed description.
Adding to Ondrej K.'s answer:
Yes, you just download the .exe and add it to your PATH. Do not run it from Bash though, because it's broken. (I'm linking to the documentation at master as of 2020-02-28 and as of 2.1.0 being the most recent version. The current master will become the release doc for 2.2.0.)
Yes, Bazel will download stuff. This includes tools for the languages you build (e.g. Java), and also external dependencies of the project.
Yes, Bazel will write to disk even if you just run it once: as Ondrej K. wrote, it will extract itself to a directory.
Do not set TEST_TMPDIR to tell Bazel where to run. Setting this envvar will make Bazel believe it's running inside a test, and it will significantly reduce its resource use and change its behavior in subtle ways you probably don't want. (If you want to limit its resource use, you can do so with several flags, see --jobs and --local_ram_resources, --local_cpu_resources.)
I've heard that it's best to wait after a new OS comes out until a few updates come in so that the build is a bit more stable. However, I'm also wondering if I will have to set up my environment, PATH, etc again after upgrading. Will updating change anything or will everything be the same as before?
(I'm currently on macOS Mojave 10.14.6)
One thing to note is that environment variables can live in different places, so it may depend on which ones you're referring to.
Usually if Mac OS upgrades need to change a file that you're likely to customize, like the httpd.conf file, they'll make a backup first. But there's no guarantee; it's good to keep a Time Machine backup handy from before you upgrade. With that you can copy in anything that got lost.
Also note that Catalina is switching the default shell from bash to zsh, so if you have environment variables in .bash_profile or .bashrc, those will be ignored. You can switch back to bash if you want, or configure zsh with similar settings.
Starting with macOS Catalina -- by default it takes zsh and hence you need to change in zprofile. Please follow below steps
touch ~/.zprofile; (// This will create the profile)
open ~/.zprofile; (Open this in an editor)
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home
export GRADLE_HOME=/Users/myuser/Documents/installs/gradle-6.8.3
export PATH=$PATH:/Users/myuser/Documents/installs/gradle-6.8.3/bin
source ~/.zprofile (Execute the new .zprofile by either restarting the terminal window or using this)
I am trying to compile an Xcode project that uses scripts to build some external (go) code. These scripts were build with the assumption that their external dependencies are on the $PATH. However, I am so far unable to get Xcode to use a PATH environment variable that includes the additions I need.
Is there a way to do this WITHOUT having to edit the Xcode project itself or the scripts? (I really don't want to edit these as these are shared with a larger team)
I have tried to use the LaunchAgents approach suggested in for example https://support.shotgunsoftware.com/hc/en-us/articles/219042108-Setting-global-environment-variables-on-OS-X, but haven't had success with it.
Wherever the script is called in xcode, that call would have to be amended to include the desired environment variable- but you don't want to modify the project. I would suggest putting symbolic links to the external dependencies somewhere in the default $PATH, where your scripts are expecting them to be.
I want to setup project specific .lldbinit files, so that "everything" would be under version control and easily setup in new computers. However it seems like I can read only ~/.lldbinit file and not any ~/git/project/.lldbinit files.
LLDB manual say:
lldb will read settings/aliases/commands from three files at startup, if
they exist.
First, it will read a ~/.lldbinit-debugger command file. If you are
using the lldb command line interface, this is ~/.lldbinit-lldb. If you
are using lldb inside a GUI debugger like Xcode this will be ~/.lldbinit-
Xcode. This is a useful place to put settings that you want to apply
only when a given lldb command interpreter is used.
Second, ~/.lldbinit is read.
Third, an .lldbinit file in the current working directory (where lldb is
started) will be read.
So my question is: how do I setup Xcode or project to use the "third" option i.e. read .lldbinit file from the current working directory? How would I check or change what's Xcode's "current working directory"?
Xcode now (written with the public Xcode 12) has support for setting a scheme-level LLDB Init File. This can be done as part of the Info tab in the Run phase of the scheme.
Open project in Xcode.
⌘ + Shift + , to open scheme editor.
Select Run then the Info tab.
Edit LLDB Init File value.
Use $(PROJECT_DIR) to reference the directory that contains the project.
Use $(SRCROOT) to reference the target's source root directory.
This is the working directory in which you launch whatever process loads the LLDB framework. Xcode doesn't have a useful working directory (it was / last time I looked), so you can't really use the cwd version.
A solution for Xcode project specific lldb settings that will work in many cases is to put a symbolic breakpoint on main, set it to auto-continue, then put the settings you want in the breakpoint commands of that breakpoint.
It would also be great if Xcode had some UI to specify target-specific lldbinit files.
There is now a "Xcode plugin to load project specific .lldbinit" at https://github.com/alloy/lldb-is-it-not
Xcode now has support for Target specific lldb init files. There's an entry form for the path to the file in the Run scheme for the Xcode target.
I currently have a project that I'm building with a makefile. This project includes some additional software (jflex) which is not on one of the default system search paths (it's installed to (/opt/local/bin/). My .profile file adds this directory to my PATH, and so building the project from a terminal window succeeds.
However, if I try to run the makefile from within XCode (XCode project with an externally managed makefile), it fails since it's not looking in /opt/local/bin for jflex, and as such can't find it.
How can I change the settings of my XCode project to correctly build from within XCode? I assume there's some kind of path setting in XCode, or some kind of additional argument I can have XCode give to make so that it doesn't fail. Alternately, I could hardcode the path into my makefile if I could detect that it was being run from XCode (although this is the less preferable option for me, since my makefile will sometimes need to be called from the command line and I'd rather keep it simple).
I'm relatively new to using XCode, so apologies if I've missed something obvious.
Instead of calling make directly, you could call a shell script as the "Build Tool" in the "External Build Tool Configuration" pane. Then modify the path in the shell script and call make from there, i.e.
#!/bin/sh
PATH=/opt/local/bin:$PATH
make
Don't forget to set permissions such that Xcode can run the script, and provide the full path to the script as the "Build Tool".
May not be the best way, But can you launch XCode from command line. It will inherit the Path from it.
Or, in the XCode launcher change:
XCode
to
PATH=$PATH:/opt/local/bin/ XCode
may work (depending on launcher)
Or, did you relaunch the launcher/window manager (logout and back in again after setting .profile)?