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).
next prev parent 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