This is the mail archive of the
mailing list for the GDB project.
Re: [RFA/python:2/2] First script in GDB python library - command/pahole.py
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Thu, 3 Jun 2010 08:34:59 -0700
- Subject: Re: [RFA/python:2/2] First script in GDB python library - command/pahole.py
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <20100603001115.GJ3019@adacore.com> <AANLkTinQuOhqR8FPN8_cRp1F5Gwa3uJeKg9OfrywOYhI@mail.gmail.com>
> just have
> I like the consistency of the former, but I'm not sure what to do
> about prefixes that already exist, e.g. enable, disable.
Hmm, right, I hadn't thought about that. IMO, there should not be a
prefix.py or subprefix.py if that prefix/subprefix command is not
a valid command in itself, or if the command already exists.
> Or what to do if there are multiple command directories and several
> have commands with the same prefix.
I guess we'll have to think about that one too, eventually. I think
the thing to do when that can happen is to print a warning/error saying
that such and such py script could not be run because it collides with
another script that was run earlier. Or print a warning saying that
a given command from such and such script was overriden by such and
such script (we might want to give precedence to user-provided scripts
over system-provided scripts for instance).
> Prescanning the directories and creating stubs sounds reasonable.
> How much of a stub though?
> In addition to command completion there is help and apropos.
I think that if we want to have help and apropos working, we might
as well just use the simpler approach of running the command scripts
right from the start. I'd be OK with that too, and it's certainly
much simpler to work on. Otherwise, to get the help, we'd have to
either evaluate part of the script, or find a way to provide that
information without doing the evaluation. Either way, I think that
it would take us past the overkill point.