This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Windows/RFA/commit] Deprecate windows-specific dll-symbols command and aliases


> I'm not sure I agree with that policy.  I mean, we shouldn't advertise
> them, yes, and I think we do hide deprecated commands in the CLI
> at places, IIRC, but as long as they exist, I think they should
> be documented.  IMO, it'd be nicer to users who are currently using
> such commands, and find out they're deprecated (because GDB warns) if
> they go to the manual and find both the replacement they should be
> using (and how), and the docu for the old command, so they can easily
> map arguments, etc.  IOW, IMO, we should instead add a "This command is
> deprecated; a better alternative is blah blah" note.  When I grep
> for deprecate_cmd, and then look for the documentation of the
> corresponding deprecated commands, I do find it.
> E.g., "record restore", "disable tracepoint", "set remotebreak", etc.

My 2 cents: I think it's fine to either remove the documentation, or
else leave it as is. Adding more info as you suggest is indeed making
the documentation better, but only for a short period of time. During
that period of time, if people happen to read about the deprecated
command in the manual, and then actually use that function, they'll
immediately get a warning, the warning will tell them which command to
use in its place. On the other hand, if we excise the commands'
documentation and they are searching the users manual, the only
command they can find are the non-deprecated ones.

In that respect, I now tend to agree with Eli. But it's not a strong
opinion.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]