Check out CommandInterpreter::SourceInitFile. It looks like it uses the
following algorithm:
---------------
if (there is .lldbinit file side-by-side)
use it
else
{
if (there is an app-specific lldbinit file in the home directory)
use it
else if (there is an lldbinit file in the home directory)
use it
}
load settings from the lldb init file that was found.
---------------
Maybe it could change to something like this:
---------------
if (there is an lldb init file in the home directory)
load settings from it
if (there is an app-specific lldbinit file in the home directory)
load it too, overwriting values that have already been set.
if (there is an lldbinit file side-by-side with the application)
load it too, overwriting values that have already been set.
On Thu, Sep 4, 2014 at 9:25 AM, Todd Fiala <tfi...@google.com> wrote:
> Hi all,
>
> Do we have any existing way to handle conditionally making settings based
> on lldb version, within the .lldbinit system?
>
> The specific case I have in mind is helping support side-by-side lldb
> installs (e.g. on debian/ubuntu) where, across lldb 3.4, 3.5 and 3.6, the
> python path to the correct lldb python module differs. Right now, the
> default behavior is that lldb 3.5 and 3.6 are picking up the older 3.4 lldb
> python library and choking due to the mismatch.
>
> Thanks for any thoughts on this!
>
> -Todd
>
>
> _______________________________________________
> 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
