How to get XCode to use bash environment variables.
phil.pel...@gmail.com
For example in:
Project -> Edit Project Settings -> [ Build ] -> Header Search Paths
I would like to be able to do something like this:
$(mypath)/include
However, when I type that in there, all I see is "/include" - it's
pretty bizarre. If I bring up a terminal window, and do a "set" (with
no arguments), I can see my environment variable (mypath).
I saw something on a wxWiki: http://www.wxwidgets.org/wiki/index.php/Setting_Environment_Variable_For_XCode
Which described something similar to what I wanted to do, but it looks
like if I do that, I can't 1.) script it (i.e. I want to have a
setup.sh that developers can simply run to setup) and 2.) have
environment variables depend on other environment variables (i.e.
mypath=$(myotherpath)/mypath).
Does anyone have ideas on how I can do this?
Thanks in advance,
-phil
{D85068A3-65DA-4661-933C-AA34590E10F5}
Tom Harrington
phil.pel...@gmail.com wrote:
> I would like to get XCode to use bash environment variables.
>
> For example in:
>
> Project -> Edit Project Settings -> [ Build ] -> Header Search Paths
>
> I would like to be able to do something like this:
>
> $(mypath)/include
>
> However, when I type that in there, all I see is "/include" - it's
> pretty bizarre. If I bring up a terminal window, and do a "set" (with
> no arguments), I can see my environment variable (mypath).
Since Xcode is not run by bash, nor associated with bash in any way, the
existence of an environment variable in bash has no effect on what's
available to Xcode. Forget bash, it's not going to help here.
> I saw something on a wxWiki:
> http://www.wxwidgets.org/wiki/index.php/Setting_Environment_Variable_For_XCode
>
> Which described something similar to what I wanted to do, but it looks
> like if I do that, I can't 1.) script it (i.e. I want to have a
> setup.sh that developers can simply run to setup) and 2.) have
> environment variables depend on other environment variables (i.e.
> mypath=$(myotherpath)/mypath).
That page describes the right way to set environment variables so that
they'll be available to Mac OS X applications in general, not just for
Xcode. The file described there is essentially the Mac OS X GUI
equivalent of bash's .bash_profile, at least with regard to environment
variables.
If the property list is in XML format, you could script modifications to
it, but you're still stuck with it not taking effect until the user logs
out and back in. This parallels the fact that an edit to .bash_profile
has no effect until a new bash session starts, except that you can't
have multiple GUI sessions for the same user. However if the property
list ends up in binary plist format you'd be out of luck.
> Does anyone have ideas on how I can do this?
Hard code the paths? Or else explain why you're trying to do this, and
see if someone has a better approach.
--
Tom "Tom" Harrington
MondoMouse makes your mouse mightier
See http://www.atomicbird.com/mondomouse/
phil.pel...@gmail.com
wrote:
> In article <1184163672.145478.83...@a26g2000pre.googlegroups.com>,
>
> phil.pellouch...@gmail.com wrote:
> > I would like to get XCode to use bash environment variables.
>
> > For example in:
>
> > Project -> Edit Project Settings -> [ Build ] -> Header Search Paths
>
> > I would like to be able to do something like this:
>
> > $(mypath)/include
>
> > However, when I type that in there, all I see is "/include" - it's
> > pretty bizarre. If I bring up a terminal window, and do a "set" (with
> > no arguments), I can see my environment variable (mypath).
>
> Since Xcode is not run by bash, nor associated with bash in any way, the
> existence of an environment variable in bash has no effect on what's
> available to Xcode. Forget bash, it's not going to help here.
>
> > I saw something on a wxWiki:
>
> > Which described something similar to what I wanted to do, but it looks
> > like if I do that, I can't 1.) script it (i.e. I want to have a
> > setup.sh that developers can simply run to setup) and 2.) have
> > environment variables depend on other environment variables (i.e.
> > mypath=$(myotherpath)/mypath).
>
> That page describes the right way to set environment variables so that
> they'll be available to Mac OS X applications in general, not just for
> Xcode. The file described there is essentially the Mac OS X GUI
> equivalent of bash's .bash_profile, at least with regard to environment
> variables.
>
> If the property list is in XML format, you could script modifications to
> it, but you're still stuck with it not taking effect until the user logs
> out and back in. This parallels the fact that an edit to .bash_profile
> has no effect until a new bash session starts, except that you can't
> have multiple GUI sessions for the same user. However if the property
> list ends up in binary plist format you'd be out of luck.
>
> > Does anyone have ideas on how I can do this?
>
> Hard code the paths? Or else explain why you're trying to do this, and
> see if someone has a better approach.
>
> --
> Tom "Tom" Harrington
> MondoMouse makes your mouse mightier
> Seehttp://www.atomicbird.com/mondomouse/
The reason to do this is because I would like to have things based on
environment variables which I can easily change, rather than having
tons of projects with hardcoded paths, such that when I need to change
the path of something, I'll have to change it in every single project.
For example - suppose I am using a third party library called "foo",
so then the header file is stored in ~/thirdparty/foo/1.0/include.
Suppose I have a bunch of projects that all use this third party
library. The change that could occur is that I get 1.1 of foo (they
fixed some bugs, etc...), so I put that in "~/thirdparty/foo/1.1/
include". If I hardcode all the paths in the projects, then I have to
go into every project and update the header directories to point to
the 1.1 directory - no fun. If I had an environment variable call
"$foo_include" then it would simply be a matter of changing that
environment variable to point to the new location.
-phil
Michael Ash
>> Hard code the paths? Or else explain why you're trying to do this, and
>> see if someone has a better approach.
>
> environment variables which I can easily change, rather than having
> tons of projects with hardcoded paths, such that when I need to change
> the path of something, I'll have to change it in every single project.
One approach is to use .xcconfig files. These allow you to put common
build settings in XML files, then when you need to change something you
just change it there, and all of the projects will see the change.
Another approach, perhaps simpler, would be to just use a symbolic link
that you can re-point to the new paths at will.
--
Michael Ash
Rogue Amoeba Software
glenn andreas
phil.pel...@gmail.com wrote:
> The reason to do this is because I would like to have things based on
> environment variables which I can easily change, rather than having
> tons of projects with hardcoded paths, such that when I need to change
> the path of something, I'll have to change it in every single project.
>
Source trees are your friend.
> For example - suppose I am using a third party library called "foo",
> so then the header file is stored in ~/thirdparty/foo/1.0/include.
> Suppose I have a bunch of projects that all use this third party
> library. The change that could occur is that I get 1.1 of foo (they
> fixed some bugs, etc...), so I put that in "~/thirdparty/foo/1.1/
> include". If I hardcode all the paths in the projects, then I have to
> go into every project and update the header directories to point to
> the 1.1 directory - no fun. If I had an environment variable call
> "$foo_include" then it would simply be a matter of changing that
> environment variable to point to the new location.
>
> -phil
Just make a source tree entry for your library and when you add things
from it to your project, set those entries to be relative to that source
tree variable. You can then change that value as needed, and similarly,
if you share your project with somebody that has that library somewhere
else, they can have a different value (for example, my laptop has a
different layout for sources than my main desktop machine which has its
sources on an external drive, but with source trees I can easily work on
large projects on either of them even though the layout of the files is
quite different)
David Stone
<gandreas-E8A0EF...@sn-ip.vsrv-sjc.supernews.net>,
glenn andreas <gand...@no.reply> wrote:
An alternative is to use symbolic links. So "~/thirdparty/foo/include"
would actually point at "~/thirdparty/foo/1.0/include" until version
1.1 came out, when the install script changes it to point at
"~/thirdparty/foo/1.1/include"
This has the added benefit of making roll-backs easier if it turns out
that version 1.1 is buggier than 1.0...
glenn andreas
David Stone <no.e...@domain.invalid> wrote:
> In article
> <gandreas-E8A0EF...@sn-ip.vsrv-sjc.supernews.net>,
> glenn andreas <gand...@no.reply> wrote:
>
> > In article <1184210575....@g4g2000hsf.googlegroups.com>,
> > phil.pel...@gmail.com wrote:
> >
> > > The reason to do this is because I would like to have things based on
> > > environment variables which I can easily change, rather than having
> > > tons of projects with hardcoded paths, such that when I need to change
> > > the path of something, I'll have to change it in every single project.
> > >
> >
> > Source trees are your friend.
> >
>
> An alternative is to use symbolic links. So "~/thirdparty/foo/include"
> would actually point at "~/thirdparty/foo/1.0/include" until version
> 1.1 came out, when the install script changes it to point at
> "~/thirdparty/foo/1.1/include"
The problem is that there is no easy way to specify the path to a file
in Xcode that will go through the symbolic link (since neither "drag
from the finder" nor "select via open panel" will guarantee what the
path is - you'd most likely end up getting
"~/thirdparty/foo/1.0/include" for all your files and there is no UI
provided to edit the specific path). Source trees, on the other hand,
are much easier - after adding a file, you just select that it is
relative to that source tree and your done.
Considering that source tree support in Xcode is specifically designed
to address these problem:
"This is particularly useful if you have a set of common files or
resources that are used in a number of projects and therefore cannot
live in the project folder"
>
> This has the added benefit of making roll-backs easier if it turns out
> that version 1.1 is buggier than 1.0...
It's just as easy to retarget your source tree to a different location.
phil.pel...@gmail.com
I did try to do this by simply creating a setup.xcconfig file and
adding "HEADER_SEARCH_PATHS = " into it and then went to project ->
edit project settings -> "Based on: " setup.xcconfig and it still
didn't work...
-phil
ohad
1. bash environment variables (export FOO=BAR) will work if XCode is started from the same bash session (open -a xcode)
2. In order to set environment variables that are available to GUI aplications, starting from Mountain Lion launchctl should be used: http://codepulsive.blogspot.com.au/2013/11/setting-environment-variables-in-os-x.html
3. In order to use environment varialbes in XCode 7, the following command must be issued: defaults write com.apple.dt.Xcode UseSanitizedBuildSystemEnvironment -bool NO