Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] Make contrib/ari/gdb_find.sh script more configurable
Date: Wed, 12 Dec 2012 12:05:00 -0000	[thread overview]
Message-ID: <20121212120522.GU31477@adacore.com> (raw)
In-Reply-To: <001501cdd79f$a5a94c00$f0fbe400$@muller@ics-cnrs.unistra.fr>

>     As we were talking about adding gdbserver to the list of
>     directories that should also be inspected by Awk regression
>     scripts, I propose hereby a patch allowing to include directory
>     gdbtk, gdbserver or gnulib to the list of inspected directories by
>     simply exporting a variable named check_XXX_dir before running the
>     scripts.

I am personally not very fond of environment variables in general,
but I see that the script passes all arguments straight through to
the find command, so we can't add new switches...

I do note, however, that the script is really only ever called with
one argument in practice, so we could simplify the problem if we
wanted to.

Just my 2 cents:
  - for gdbserver, I assume we will make it non-optional at some point.
  - For gnulib, I think it is pointless. I do not see why we'd start
    generating ARI info for some source code that we do not control.
  - for gdbtk, why not, although I don't know that the gdbtk is
    very active beyond minimal maintenance...

> 2012-12-11  Pierre Muller  <muller@sourceware.org>
> 
>         * contrib/ari/gdb_find.sh (add_pruned_directory): New function.
>         (check_gdbtk_dir, check_gdbserver_dir, check_gnulib_dir): Add
>         test for presence of variables to conditionally prune corresponding
>         directory.

I think the entry presents the environment variable names as entities
in your code. I don't know how to present changes to the "main" of
a script. I'd probably write a free-txt description of the changes
and see if I get away with it.

        * contrib/ari/gdb_find.sh: Check the "check_gdbtk_dir",
        "check_gdbserver_dir", and "check_gnulib_dir" environment
        variables to determine which directories should get pruned.

Or something like that.

-- 
Joel

PS: One of the issues I have with the current scripts is that they are
    pretty abstract. They were most likely written to handle several
    projects, with GDB being just one of them. Now that the scripts
    are inside the GDB repository, I'd enjoy some simplications in
    that department (Eg: delete variable "project", and just inline
    "gdb" everywhere - it seems like it would make the code a little
    easier to understand).


  reply	other threads:[~2012-12-12 12:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11 13:01 Pierre Muller
2012-12-12 12:05 ` Joel Brobecker [this message]
2012-12-12 12:39   ` Pedro Alves
     [not found] <50c72eb9.c7f1440a.18e7.ffff89d4SMTPIN_ADDED_BROKEN@mx.google.com>
2012-12-12 12:44 ` Pedro Alves

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=20121212120522.GU31477@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pierre.muller@ics-cnrs.unistra.fr \
    /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