public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH 0/8] Make the BFD info manual a bit prettier
Date: Thu, 16 Feb 2023 09:40:52 +0000	[thread overview]
Message-ID: <b66909bb-419b-d87a-6623-2effb1ed0972@redhat.com> (raw)
In-Reply-To: <87ttzmbnsk.fsf@tromey.com>

Hi Tom,

> While I like FORTH well enough, I suspect it might be nicer to just
> rewrite chew in Python. 

My first thought is - "if it ain't broke, don't fix it" - as in, what
do you gain from rewriting chew ?  Is it just so that it is easier to
maintain in the future, should bugs be encountered, or to make it easier
to add new features, or what ?

Don't get me wrong.  If there are good reasons for rewriting chew then
I am willing to listen, but if it is working as-is then I would prefer
to leave well enough alone.


> Over in gdb, we've standardized on that for all
> our maintainer scripts; the main benefits are that a lot of people know
> it and there are plenty of libraries, etc, to use.  What do you think of
> this?

It would add a new dependency for the binutils.  Currently there are no
python scripts being used to build or test the binutils.  Not that this
is necessarily a bad thing.  But if there are alternatives to using python
that would work just as well (bash scipts ?) then maybe that would be
better.


> Finally, it seems to me that it would be nicer if chew were merely a
> documentation extractor.  Having it also generate source files seems
> unfortunate.  For example, things like 'tags' don't work, because the
> primary source code is actually in some comment somewhere.  It seems
> like this could be changed so that code is just code, comments (and
> maybe snippets of code) are extracted into the manual, and some of the
> generated headers are turned into ordinary headers.  WDYT?

I am ambivalent.  I do not use 'tags' myself, so not having it work on
the generated source files is not a big deal for me.  But I can see that
it would be annoying for people who do use it.  I do worry that rewriting
this code will introduce new bugs into an area of the binutils that is
currently working just fine.

If you are passionate about this idea, then please go ahead.  But if you
have 10 other projects clamouring for your attention, then maybe leave this
one on the back-burner.

Cheers
   Nick


      reply	other threads:[~2023-02-16  9:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08  7:17 Tom Tromey
2023-02-08  7:17 ` [PATCH 1/8] Remove H_CFLAGS from doc/local.mk Tom Tromey
2023-02-08  7:17 ` [PATCH 2/8] Simplify @node use in BFD documentation Tom Tromey
2023-03-03  8:20   ` Jan Beulich
2023-03-03 23:08     ` Tom Tromey
2023-03-06  7:07       ` Jan Beulich
2023-02-08  7:17 ` [PATCH 3/8] Add copyright headers to the .str files Tom Tromey
2023-02-08  7:17 ` [PATCH 4/8] Remove the paramstuff word Tom Tromey
2023-02-08  7:17 ` [PATCH 5/8] Use intptr_t rather than long in chew Tom Tromey
2023-02-08  7:17 ` [PATCH 6/8] Change internalmode to be an intrinsic variable Tom Tromey
2023-02-08  7:17 ` [PATCH 7/8] Use @deftypefn in chew output Tom Tromey
2023-02-15 17:55   ` Simon Marchi
2023-02-15 23:11     ` Tom Tromey
2023-02-16  1:29       ` Simon Marchi
2023-02-19  3:46         ` Alan Modra
2023-02-08  7:17 ` [PATCH 8/8] Remove RETURNS from BFD chew comments Tom Tromey
2023-02-15  9:54 ` [PATCH 0/8] Make the BFD info manual a bit prettier Nick Clifton
2023-02-15 21:51   ` Tom Tromey
2023-02-16  9:40     ` Nick Clifton [this message]

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=b66909bb-419b-d87a-6623-2effb1ed0972@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=tom@tromey.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).