If this is for the PYTHONHOME stuff, then could we solve this in a way similar to what I suggested on IRC? Basically, for Windows specifically, we either assume that python is installed into a specific location relative to the lldb executable, or look for an environment variable like LLDB_PYTHON_LOCATION (different from PYTHONHOME since that would be used by other installed versions of python as well).
On Wed Jan 28 2015 at 11:55:02 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
