How to get XCode to use bash environment variables.

Discussion in 'Programmer Help' started by phil.pellouchoud@gmail.com, Jul 11, 2007.

  1. Guest

    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).

    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}
     
    , Jul 11, 2007
    #1
    1. Advertisements

  2. Guest

    On Jul 11, 8:50 am, Tom Harrington <>
    wrote:
    > In article <>,
    >
    > 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_...

    >
    > > 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
     
    , Jul 12, 2007
    #2
    1. Advertisements

  3. David Stone Guest

    In article
    <-sjc.supernews.net>,
    glenn andreas <> wrote:

    > In article <>,
    > 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)


    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...
     
    David Stone, Jul 12, 2007
    #3
  4. Guest

    On Jul 11, 9:13 pm, Michael Ash <> wrote:
    > wrote:
    > >> Hard code the paths? Or else explain why you're trying to do this, and
    > >> see if someone has a better approach.

    >
    > > 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.

    >
    > 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


    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
     
    , Jul 15, 2007
    #4
  5. ohad New Member

    Joined:
    Oct 20, 2015
    Messages:
    1
    Likes Received:
    0
    A couple of comments for future readers (apologies for the resurrection, but this post comes up high in related searches):
    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
     
    ohad, Oct 20, 2015
    #5
    1. Advertisements

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads
  1. Mike D.
    Replies:
    3
    Views:
    287
    Eric Albert
    Dec 11, 2003
  2. Get XCode to Use My Version of Java

    , Aug 8, 2006, in forum: Programmer Help
    Replies:
    0
    Views:
    275
  3. Replies:
    3
    Views:
    332
  4. KraftDiner
    Replies:
    0
    Views:
    257
    KraftDiner
    Aug 15, 2006
  5. SpreadTooThin

    Setting environment variables...

    SpreadTooThin, Aug 27, 2007, in forum: Mac
    Replies:
    3
    Views:
    294
    Jochem Huhmann
    Aug 28, 2007
  6. Peter James

    Changing environment variables

    Peter James, Mar 16, 2008, in forum: Mac
    Replies:
    17
    Views:
    336
    Martin Smith
    Mar 18, 2008
  7. Replies:
    14
    Views:
    368
    Barry Margolin
    Apr 16, 2010
  8. NKunkel
    Replies:
    0
    Views:
    513
    NKunkel
    Jun 4, 2012
Loading...