[lldb-dev] Global lldbinit file?

Thu Jan 29 09:47:32 PST 2015

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.woodward at 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:zturner at google.com]
> *Sent:* Thursday, January 29, 2015 10:33 AM
> *To:* Ted Woodward; Greg Clayton
>
>
> *Cc:* Jim Ingham; lldb-dev at 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.woodward at 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:zturner at google.com]
> *Sent:* Wednesday, January 28, 2015 10:08 PM
> *To:* Greg Clayton; Ted Woodward
> *Cc:* Jim Ingham; lldb-dev at 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 <gclayton at 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.woodward at 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: jingham at apple.com [mailto:jingham at apple.com]
> > Sent: Wednesday, January 28, 2015 1:40 PM
> > To: Zachary Turner
> > Cc: Ted Woodward; lldb-dev at 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 <zturner at 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.woodward at 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: jingham at apple.com [mailto:jingham at apple.com]
> >> Sent: Wednesday, January 28, 2015 1:12 PM
> >> To: Ted Woodward
> >> Cc: lldb-dev at 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.woodward at 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 at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> lldb-dev mailing list
> >> lldb-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >> _______________________________________________
> >> lldb-dev mailing list
> >> lldb-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150129/7cda02fe/attachment.html>