<div dir="ltr"><div>Ahh, I was conflating the issue of PYTHONHOME/PYTHONPATH with that of the global init file, but they solve different problems.  </div><div><br></div><div>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.</div><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 8:40 AM Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Right. If the community doesn’t want an installation-global lldbinit file, I’ll just modify the drivers as suggested earlier.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">To replace my wrapper scripts, I need that, and a way to find the python install automatically. I’ve just about got the 2^nd one done </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Qualcomm Innovation Center, Inc.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Zachary Turner [mailto:<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>] <br><b>Sent:</b> Thursday, January 29, 2015 10:33 AM<br><b>To:</b> Ted Woodward; Greg Clayton</span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br><b>Cc:</b> Jim Ingham; <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br><b>Subject:</b> Re: [lldb-dev] Global lldbinit file?<u></u><u></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><div><p class="MsoNormal">On Thu, Jan 29, 2015 at 8:26 AM Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Qualcomm Innovation Center, Inc.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Zachary Turner [mailto:<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>] <br><b>Sent:</b> Wednesday, January 28, 2015 10:08 PM<br><b>To:</b> Greg Clayton; Ted Woodward<br><b>Cc:</b> Jim Ingham; <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a></span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br><b>Subject:</b> Re: [lldb-dev] Global lldbinit file?</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">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.  <u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div></div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On Wed Jan 28 2015 at 12:32:12 PM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><p class="MsoNormal" style="margin-bottom:12.0pt">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.<br><br>Maybe we can start paving the way for bundles on windows and linux with LLDB?<br><br>Greg<br><br>> On Jan 28, 2015, at 11:54 AM, Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>> wrote:<br>><br>> All the llvm tools in our installation have "hexagon-" prepended too them, so lldb is really hexagon-lldb.<br>><br>> Right now we use a wrapper script that looks something like this:<br>><br>> DIR=$(dirname $0)<br>> export PYTHONHOME=$DIR/..<br>> exec $DIR/hexagon-lldb-3.5.0 -o "command script import $DIR/hexagon_utils.py" "$@"<br>><br>> 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.<br>><br>> --<br>> Qualcomm Innovation Center, Inc.<br>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>><br>> -----Original Message-----<br>> From: <a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a> [mailto:<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>]<br>> Sent: Wednesday, January 28, 2015 1:40 PM<br>> To: Zachary Turner<br>> Cc: Ted Woodward; <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>> Subject: Re: [lldb-dev] Global lldbinit file?<br>><br>> First off, the fact that git does something at the user-interface level seems rather an argument against doing it that for...<br>><br>> 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...<br>><br>> Jim<br>><br>>> On Jan 28, 2015, at 11:27 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>>><br>>> 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.<br>>><br>>> 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.<br>>><br>>> On Wed Jan 28 2015 at 11:21:13 AM Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>> wrote:<br>>> I'm sorry; I wasn't clear. When I say "global", I mean "global to this installation", not "global to the system".<br>>><br>>> My idea was something like /inst/hexagon/Tools/bin/lldb would load /inst/hexagon/Tools/bin/<u></u>lldbinit. Another lldb installation, say /inst/Xcode/bin/lldb, wouldn't see it, or be affected by it.<br>>><br>>> --<br>>> Qualcomm Innovation Center, Inc.<br>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>>><br>>> -----Original Message-----<br>>> From: <a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a> [mailto:<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>]<br>>> Sent: Wednesday, January 28, 2015 1:12 PM<br>>> To: Ted Woodward<br>>> Cc: <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>>> Subject: Re: [lldb-dev] Global lldbinit file?<br>>><br>>> 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.<br>>><br>>> 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...<br>>><br>>> 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.<br>>><br>>> Jim<br>>><br>>><br>>><br>>><br>>><br>>>> On Jan 28, 2015, at 9:40 AM, Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>> wrote:<br>>>><br>>>><br>>>> When LLDB launches, it will read ~/.lldbinit (and possibly other variants of that, like ~/.lldbinit-Xcode).<br>>>><br>>>> 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.<br>>>><br>>>> Do we have a global lldbinit file, or should I add code to load Host::GetProgramFileSpec()/<u></u>lldbinit?<br>>>><br>>>> --<br>>>> Qualcomm Innovation Center, Inc.<br>>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>>>><br>>>> ______________________________<u></u>_________________<br>>>> lldb-dev mailing list<br>>>> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>>><br>>><br>>><br>>> ______________________________<u></u>_________________<br>>> lldb-dev mailing list<br>>> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>>> ______________________________<u></u>_________________<br>>> lldb-dev mailing list<br>>> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>><br>><br>><br>> ______________________________<u></u>_________________<br>> lldb-dev mailing list<br>> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><u></u><u></u></p></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div>