Ahh, I was conflating the issue of PYTHONHOME/PYTHONPATH with that of the global init file, but they solve different problems.
One thing I'm curious to see how your PYTHONHOME/PYTHONPATH patch addresses is that of number of CMake variables. I already have to set 3 CMake variables just for python. PYTHON_LIBRARY, PYTHON_EXECUTABLE, and PYTHON_INCLUDE_DIR. I'm not too crazy about having to set 2 more in addition to these. Unfortunately CMake's FindPythonLibs package doesn't work correctly on Windows, so there's not a good workaround for having to set all these variables manually other than to just not use the package. On Thu, Jan 29, 2015 at 8:40 AM Ted Woodward <ted.woodw...@codeaurora.org> wrote: > Right. If the community doesn’t want an installation-global lldbinit file, > I’ll just modify the drivers as suggested earlier. > > > > To replace my wrapper scripts, I need that, and a way to find the python > install automatically. I’ve just about got the 2nd one done J > > > > -- > > Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > > *From:* Zachary Turner [mailto:ztur...@google.com] > *Sent:* Thursday, January 29, 2015 10:33 AM > *To:* Ted Woodward; Greg Clayton > > > *Cc:* Jim Ingham; lldb-dev@cs.uiuc.edu > *Subject:* Re: [lldb-dev] Global lldbinit file? > > > > that still doesn't address your initial concern does it? Otherwise there > would be no need for the global lldbinit file. What im suggesting removes > the need for a PYTHONHOME and PYTHONPATH entirely, and instead relies on a > one-time system setting. > > On Thu, Jan 29, 2015 at 8:26 AM Ted Woodward <ted.woodw...@codeaurora.org> > wrote: > > I’ve got a patch that’s being reviewed internally that lets you set cmake > variables to set the default PYTHONHOME and PYTHONPATH. These get passed in > on the compile line and are used to set PYTHONHOME and PYTHONPATH, if > they’re not in the environment. I hope to have it done and up on > phabricator soon. It works on Windows and Linux, and I assume other Unix > variants. > > > > -- > > Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > > *From:* Zachary Turner [mailto:ztur...@google.com] > *Sent:* Wednesday, January 28, 2015 10:08 PM > *To:* Greg Clayton; Ted Woodward > *Cc:* Jim Ingham; lldb-dev@cs.uiuc.edu > > > *Subject:* Re: [lldb-dev] Global lldbinit file? > > > > I'm not too familiar with how bundles work on MacOSX, but I think having > LLDB just be able to know where to look without any special configuration > is the way to go. It sounds like that's what bundles solve. In the > interim I think a possible solution for this on Windows is to just have > LLDB look for LLDB_PYTHON_HOME. If it finds it, it will expect to find > Python there and call PySys_SetPath appropriately during initialization. > If it doesn't, then it's up to the user to have a properly configured > PYTHONHOME and PYTHONPATH. > > > > This way, on hexagon machines, installation of LLDB could involve setting > this environment variable to the appropriate value. It would also be > useful for non-hexagon Windows as well, because the current state of > affairs requires you to have a bunch of environment variables pointing to > the correct locations on your disk, which is not very user friendly and a > source of error when trying to build on Windows. > > > > On Wed Jan 28 2015 at 12:32:12 PM Greg Clayton <gclay...@apple.com> wrote: > > Then you should be able to have a ".lldbinit-hexagon-lldb" file that will > get sourced. The main questions is if there is a good place to put this > file when there are no bundles on linux or windows. On LLDB, the > LLDB.framework contains everything we need (headers, resources, support > binaries (debugserver, lldb-gdbserver lldb-platform, darwin-debug, and > more) and the lldb python modules. > > Maybe we can start paving the way for bundles on windows and linux with > LLDB? > > Greg > > > On Jan 28, 2015, at 11:54 AM, Ted Woodward <ted.woodw...@codeaurora.org> > wrote: > > > > All the llvm tools in our installation have "hexagon-" prepended too > them, so lldb is really hexagon-lldb. > > > > Right now we use a wrapper script that looks something like this: > > > > DIR=$(dirname $0) > > export PYTHONHOME=$DIR/.. > > exec $DIR/hexagon-lldb-3.5.0 -o "command script import > $DIR/hexagon_utils.py" "$@" > > > > I'd like to replace the '-o "command script import > $DIR/hexagon_utils.py"' with something that gets loaded automatically, so I > can set PYTHONHOME and just run hexagon-lldb-3.5.0 and get my utility > scripts. I can do this with custom drivers (1 for lldb, 1 for lldb-mi), but > I'd hoped to stay as close to the upstream code as possible. > > > > -- > > Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > > -----Original Message----- > > From: jing...@apple.com [mailto:jing...@apple.com] > > Sent: Wednesday, January 28, 2015 1:40 PM > > To: Zachary Turner > > Cc: Ted Woodward; lldb-dev@cs.uiuc.edu > > Subject: Re: [lldb-dev] Global lldbinit file? > > > > First off, the fact that git does something at the user-interface level > seems rather an argument against doing it that for... > > > > But also, in git's case it makes some sense to have global > configurations, for instance to implement policies for everybody on a team, > or something like that. But I don't see that strong a use case for that > for lldb. Plus, the particular instance seems another counter-argument, > since as I understand it the Hexagon init is going to change the behavior > of lldb significantly. I would rather if that happen I know this is not > vanilla lldb, because it is called "lldb-hex" or something... > > > > Jim > > > >> On Jan 28, 2015, at 11:27 AM, Zachary Turner <ztur...@google.com> > wrote: > >> > >> Personally I'm a big fan of this model. Sort of like what git does, > where you have different install files in different scopes, and it starts > by parsing the global config first, then the user-level config, then the > local config, overwriting values in the process. > >> > >> So in Ted's scenario, for example, maybe lldb could load ~/.lldbinit > first, then look in the same folder as the executable for a .lldbinit and > load it second. > >> > >> On Wed Jan 28 2015 at 11:21:13 AM Ted Woodward < > ted.woodw...@codeaurora.org> wrote: > >> I'm sorry; I wasn't clear. When I say "global", I mean "global to this > installation", not "global to the system". > >> > >> My idea was something like /inst/hexagon/Tools/bin/lldb would load > /inst/hexagon/Tools/bin/lldbinit. Another lldb installation, say > /inst/Xcode/bin/lldb, wouldn't see it, or be affected by it. > >> > >> -- > >> Qualcomm Innovation Center, Inc. > >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > >> > >> -----Original Message----- > >> From: jing...@apple.com [mailto:jing...@apple.com] > >> Sent: Wednesday, January 28, 2015 1:12 PM > >> To: Ted Woodward > >> Cc: lldb-dev@cs.uiuc.edu > >> Subject: Re: [lldb-dev] Global lldbinit file? > >> > >> This worries me a little bit. I install your Hexagon lldb, and that > installs a global lldbinit, which then starts affecting my use of the other > lldb's I happen to have on my system in ways that are not at all clear to > me... That doesn't seem like a good idea to me. > >> > >> gdb had a global configuration file in /etc/conf, and Apple's gdb > installation used it for a few things (this was actually done at NeXT and > NOT by me...) - mainly setting some common print variables. But this just > ended up causing more confusion than it was worth. It would have been > better to just bake these into the gdb driver we shipped... > >> > >> I would suggest distributing your lldb as lldb-hex or something like > that, and including a template .lldbinit-hex that folks could install, or > making your own driver that sets the options you want first. > >> > >> Jim > >> > >> > >> > >> > >> > >>> On Jan 28, 2015, at 9:40 AM, Ted Woodward <ted.woodw...@codeaurora.org> > wrote: > >>> > >>> > >>> When LLDB launches, it will read ~/.lldbinit (and possibly other > variants of that, like ~/.lldbinit-Xcode). > >>> > >>> In my Hexagon LLDB installation, I want LLDB to always load a global > lldbinit file. Currently I do this by having lldb be a wrapper script that > calls lldb with –o, but I’d like to eliminate the wrapper script, since > wrapper batch files cause problems with ctrl-c handling on Windows. I use > this to load a python file with utilities in it, like one to get the TLB > info from the target. It sends a qXfer command to the remote GDB server to > download an XML file, parses it, and prints the info from it. These > utilities need to load for all users. > >>> > >>> Do we have a global lldbinit file, or should I add code to load > Host::GetProgramFileSpec()/lldbinit? > >>> > >>> -- > >>> Qualcomm Innovation Center, Inc. > >>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > >>> > >>> _______________________________________________ > >>> lldb-dev mailing list > >>> lldb-dev@cs.uiuc.edu > >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >> > >> > >> > >> _______________________________________________ > >> lldb-dev mailing list > >> lldb-dev@cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >> _______________________________________________ > >> lldb-dev mailing list > >> lldb-dev@cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
