> On Jul 2, 2014, at 5:35 PM, Zachary Turner <[email protected]> wrote: > > Ok, I'll think about this approach some more. It's funny that I'm of the > opposite mind when it comes to the dependent help text. As I would only ever > be interested in seeing help for the selected target. Would it be ok to add > an option to help (for example "help -t") that hides options not relevant to > the current target?
That seems fine to me. If we had some tool that did "extract all the help text for all the targets and organize them into something with a table of contents and an index" I probably wouldn't feel so strongly about this. But since the online help is currently the only source for this information I don't want to make it state-dependent... Jim > > > > > On Wed, Jul 2, 2014 at 5:17 PM, <[email protected]> wrote: > > > On Jul 2, 2014, at 4:53 PM, Zachary Turner <[email protected]> wrote: > > > > On Wed, Jul 2, 2014 at 4:36 PM, <[email protected]> wrote: > > > > Then the way command objects work is that their options are baked into the > > object handed to the command interpreter when they are added to the > > interpreter. There's one command object for a given command name > > registered at startup. I'm not sure how excited I am about swapping these > > things in and out as the currently selected Platform/Target/Process > > changes. For instance, if you could very well be running a command for > > with TargetA currently selected in the main lldb interpreter, and at the > > same time the process in TargetB could hit a breakpoint and want to run > > some commands for its breakpoint action... It would be a pain to juggle > > that sort of thing... It would be much simpler to keep all the options in > > one command object, and have the context in which the command is running > > determine the validity of the commands options. > > > > What about attaching a (possibly different) CommandInterpreter to each > > Platform object? They could differ arbitrarily. So if TargetA hits a > > breakpoint followed by TargetB, we would just go through each Target's > > attached interpreter, and everything should "just work". > > I have a bad feeling about this, it seems like adding some tricky bits of > complexity. For instance the interpreters are not independent, a breakpoint > action that did: > > target select TargetB > some commands > > will now have to swap command interpreters in mid-flight. You'd also have to > teach the interpreters to share a Python interpreter (since you want them to > shared variables, etc for cool-o cross-target debugging experiments. > > We'd also have to add a layer of heuristics on the "settings set" command, > since they are currently held by the interpreter, but often you would be > surprised if a setting didn't apply to some new target because it didn't > share the same interpreter. > > I also think it would be weird to have the help text dependent on the > currently selected target. That just seems like it would make things overly > magical. I would like a place to go to see all the options, so I have some > hope of finding that vaguely remembered one-time-it-was-useful option without > having to manually create all the platforms/targets I ever made to see which > one had it. I think it would be much better for the help to show all options > and just indicate which ones were currently available. > > Jim > > > > > > > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
