This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] --with-iconv-path
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 6 May 2011 08:12:12 -0700
- Subject: Re: [RFC] --with-iconv-path
- References: <20110506002720.DE3BF2461B1@ruffy.mtv.corp.google.com>
> We have one environment where the iconv binary comes from a
> non-standard location. This patch lets one tell gdb where to find it.
Does it mean that the libiconv libraries are at one location, and
that the binary is at a different location? Looking at your patch,
it looks like you might have a situation where the name of the iconv
binary itself is different...
> 2011-05-05 Doug Evans <dje@google.com>
>
> * configure.ac: New configure option --with-iconv-path.
> * configure: Regenerate.
> * config.in: Regenerate.
> * charset.c (find_charset_names): Use ICONV_PATH if defined.
"path" had me confused, and made me think that you were going
to pass the name of the directory where iconv is located. But
the patch seems to be contradicting that.
If we don't need to specify the name of the iconv directory,
then perhaps we could just focus on the directory name itself.
We could even make that directory name relatocatable, the same
way we make some of the paths relocatable as well.
Normally, we have sets of switches that look like this:
--with-xxx=PATH
--with-xxx-lib=PATH
--with-xxx-include=PATH
etc
We already have --with-libiconv-prefix. So, how about naming it
--with-libiconv-bin ?
If we think that it would be convenient to specify the iconv exe
as well, how about --with-libiconv-exe or --with-libiconv-program?
--
Joel