This is the mail archive of the
mailing list for the binutils project.
Re: RFC: Add --plugin-gcc option to ar/nm
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>
- Date: Tue, 18 Oct 2011 05:19:45 +0100
- Subject: Re: RFC: Add --plugin-gcc option to ar/nm
- References: <CAMe9rOrSiXbAikW70iPVEOA5O6S0q_8Bm=c0gimvfQCUjqm5MA@mail.gmail.com>
On 15/10/2011 23:44, H.J. Lu wrote:
> ---plugin option for ar/nm is very long. I am proposing to add
> a --plugin-gcc option. It can be implemented with
> 1. Move LTOPLUGINSONAME from gcc to config/plugins.m4.
> 2. Define LTOPLUGINSONAME for ar/nm.
> 3. For --plugin-gcc, ar/nm call popen using environment variable GCC if set,
> or gcc with -print-prog-name=$LTOPLUGINSONAM to get
> plugin name.
> Any comments?
Given the general "environment variables are bad and to be avoided where
possible" rule we tend to follow, and the fact that it might often be more
useful to check $CC rather than $GCC, how about letting --plugin-gcc take an
optional argument, which is used in preference to both $GCC and plain "gcc"
when provided? i.e.
3. For --plugin-gcc, ar/nm calls popen using
- the optional argument to --plugin-gcc, if provided, or
- environment variable GCC if set, or
as the executable to launch, and with "-print-prog-name=$LTOPLUGINSONAME" as
the sole command-line argument, to get the full path to the plugin.