From: Doug Evans <dje@google.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Tom Tromey <tromey@redhat.com>,
Joel Brobecker <brobecker@adacore.com>,
Pedro Alves <palves@redhat.com>,
gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Display configuration details in --help
Date: Tue, 09 Apr 2013 23:33:00 -0000 [thread overview]
Message-ID: <CADPb22SQaWrBd4MOmMqFaAMc=KnX15hd=be3Ta_u3wGg=HGmXQ@mail.gmail.com> (raw)
In-Reply-To: <83txnfa9m7.fsf@gnu.org>
On Tue, Apr 9, 2013 at 10:37 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> I have a bit of a phobia of adding more lines to gdb's initial output.
>> It's too long already IMO. [I realize there's -q.]
>> I'm not objecting per se. Just wondering how critical this is.
>
> It's not critical. But then neither is this:
>
> GNU gdb (GDB) 7.5.1
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details. ^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> So I thought we should be consistent here, and offer the same for this
> line:
>
> This GDB was configured as "i686-pc-mingw32".
>
> I'm okay with not adding that, but can someone explain why it is
> different from advertising "show copying" and "show warranty"? Should
> we remove those two as well?
I need to check, but I think(!) the "show copying" and "show warranty"
are required by GNU standards.
>> > +/* Print the details of GDB build-time configuration. */
>> > +void
>> > +print_gdb_configuration (struct ui_file *stream)
>> > +{
>> > + fprintf_filtered (stream, _("\
>> > +This GDB was configured as follows:\n\
>> > + configure --host=%s --target=%s\n\
>> > +"), host_name, target_name);
>> > + fprintf_filtered (stream, _("\
>> > + --with-auto-load-dir=%s\n\
>> > + --with-auto-load-safe-path=%s\n\
>> > +"), AUTO_LOAD_DIR, AUTO_LOAD_SAFE_PATH);
>> > +#if HAVE_LIBEXPAT
>> > + fprintf_filtered (stream, _("\
>> > + --with-expat\n\
>> > +"));
>> > +#else
>> > + fprintf_filtered (stream, _("\
>> > + --without-expat\n\
>> > +"));
>> > +#endif
>>
>> If we've already discussed this, please ignore, but ... :-)
>> I'd prefer one line per fprintf instead of three.
>
> Sorry, I'm not following: what 3 lines? Can you show how would you
> like the code be reformatted?
fprintf_filtered (stream, _(" -with-expat\n")); // assuming 2
space indentation
>> Also, is there something driving the choice of indenting 13 spaces in?
>
> It lines up to the right of "configure", below the first option:
>
> This GDB is configured as follows:
> configure --host=i686-pc-mingw32 --target=i686-pc-mingw32
> --with-auto-load-dir=$debugdir:$datadir/auto-load
> --with-auto-load-safe-path=$debugdir:$datadir/auto-load
> --with-expat
> --with-gdb-datadir=d:/usr/share/gdb (relocatable)
> --with-jit-reader-dir=d:/usr/lib/gdb (relocatable)
> --without-libunwind-ia64
> --with-lzma
> --with-python=d:/usr/Python26 (relocatable)
> --with-separate-debug-dir=d:/usr/lib/debug (relocatable)
> --with-system-gdbinit=d:/usr/etc/gdbinit (relocatable)
> --with-zlib
>
>> How about 2 or 4?
>> For consistency with print_gdb_help I'd go with 2.
>
> print_gdb_help displays a different information, so I see no need for
> consistency here. But I won't argue if others think like you do.
One could parameterize the indentation. Just a suggestion.
e.g. fprintf_filtered ("%s--with-foo", indent); // or some such [yes,
I left off _()]
>> > fputs_unfiltered (_("\
>> > --version Print version information and then exit.\n\
>> > + --configuration Print details about GDB configuration and then exit.\n\
>> > -w Use a window interface.\n\
>> > --write Set writing into executable and core files.\n\
>> > --xdb XDB compatibility mode.\n\
>>
>> The options here are (mostly) sorted alphabetically.
>
> Except where they aren't:
>
> --args Arguments after executable-file are passed to inferior
> -b BAUDRATE Set serial port baud rate used for remote debugging.
> --batch Exit after processing options.
> --batch-silent As for --batch, but suppress all gdb stdout output.
> >>> --return-child-result
> GDB exit code will be the child's exit code.
> --cd=DIR Change current directory to DIR.
> --command=FILE, -x Execute GDB commands from FILE.
> >>> --eval-command=COMMAND, -ex
> Execute a single GDB command.
> May be used multiple times and in conjunction
> with --command.
> >>> --init-command=FILE, -ix Like -x but execute it before loading inferior.
> >>> --init-eval-command=COMMAND, -iex Like -ex but before loading inferior.
> >>> --core=COREFILE Analyze the core dump COREFILE.
> >>> --pid=PID Attach to running process PID.
> --dbx DBX compatibility mode.
> --directory=DIR Search for source files in DIR.
> --epoch Output information used by epoch emacs-GDB interface.
> --exec=EXECFILE Use EXECFILE as the executable.
> --fullname Output information used by emacs-GDB interface.
> --help Print this message.
> --interpreter=INTERP
> Select a specific interpreter / user interface
> -l TIMEOUT Set timeout in seconds for remote debugging.
> --nw Do not use a window interface.
> --nx Do not read .gdbinit file.
> --quiet Do not print version number on startup.
> --readnow Fully read symbol files on first access.
> --se=FILE Use FILE as symbol file and executable file.
> --symbols=SYMFILE Read symbols from SYMFILE.
> --tty=TTY Use TTY for input/output by the program being debugged.
> --version Print version information and then exit.
> -w Use a window interface.
> --write Set writing into executable and core files.
> --xdb XDB compatibility mode.
>
> Again, I'm not really wedded to the place where I inserted the new
> option, but please tell me near which 'c' option to put it instead ;-).
Right after --command works for me.
next prev parent reply other threads:[~2013-04-09 17:53 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 17:46 Eli Zaretskii
2013-03-21 18:00 ` Doug Evans
2013-03-21 18:25 ` Pedro Alves
2013-03-21 18:29 ` Joel Brobecker
2013-03-21 18:44 ` Eli Zaretskii
2013-03-21 19:11 ` Joel Brobecker
2013-03-21 20:39 ` Eli Zaretskii
2013-03-21 20:55 ` Joel Brobecker
2013-03-21 21:17 ` Tom Tromey
2013-03-21 22:23 ` Eli Zaretskii
2013-04-09 19:31 ` Eli Zaretskii
2013-04-09 19:46 ` Doug Evans
2013-04-09 20:04 ` Eli Zaretskii
2013-04-09 23:33 ` Doug Evans [this message]
2013-04-10 0:12 ` Pedro Alves
2013-04-10 0:48 ` Eli Zaretskii
2013-04-10 2:51 ` Doug Evans
2013-04-10 4:41 ` Eli Zaretskii
2013-04-11 2:41 ` Doug Evans
2013-04-11 1:20 ` Tom Tromey
2013-04-11 1:24 ` Pedro Alves
2013-04-11 2:43 ` Tom Tromey
2013-04-12 12:50 ` Eli Zaretskii
2013-04-12 14:43 ` Eli Zaretskii
2013-04-12 16:39 ` regroup --help text (was: Re: [PATCH] Display configuration details in --help) Pedro Alves
2013-06-22 11:31 ` regroup --help text " Eli Zaretskii
2013-06-25 19:30 ` Pedro Alves
2013-07-06 7:35 ` Eli Zaretskii
2013-04-12 20:50 ` [PATCH] Display configuration details in --help Tom Tromey
2013-04-14 14:17 ` Joel Brobecker
2013-04-16 1:34 ` Doug Evans
2013-04-16 9:46 ` regroup --help text Eli Zaretskii
2013-04-17 8:10 ` Doug Evans
2013-04-17 12:28 ` Eli Zaretskii
2013-04-14 14:16 ` [PATCH] Display configuration details in --help Doug Evans
2013-04-10 0:38 ` Eli Zaretskii
2013-04-10 3:06 ` Doug Evans
2013-04-10 4:44 ` Eli Zaretskii
2013-03-21 18:53 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADPb22SQaWrBd4MOmMqFaAMc=KnX15hd=be3Ta_u3wGg=HGmXQ@mail.gmail.com' \
--to=dje@google.com \
--cc=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox