Hi Didier,
* Didier Cabannes wrote on Fri, Nov 04, 2005 at 09:24:45PM CET:
> On Fri, 2005-11-04 at 13:14 +0100, Bogdan Costescu wrote:
> > On Thu, 3 Nov 2005, Didier Cabannes wrote:
> >
> > > CC=pathcc
> > > CXX=pathCC
> > > ...
> > >> if test "$CC" = "pathCC" -a $psc_deps_depth -eq 2 ; then
> >
> > I have to confess of not looking at the actual configure script, but
> > it strikes me that you set CC to pathcc (C compiler) and later on
> > check for pathCC (C++ compiler).
>
> As you can see below the script sets CC to the C++ compiler. But don't
> ask me why.
This is part of Libtool macros doing their thin. Don't be misled, the
value of $CC is restored later correctly
> + CC=/opt/pathscale/bin/pathCC
> + compiler=/opt/pathscale/bin/pathCC
> + compiler_CXX=/opt/pathscale/bin/pathCC
> ++ echo X/opt/pathscale/bin/pathCC
> ++ sed -e 's/^X//' -e 's%^.*/%%'
> + cc_basename=pathCC
By the way, it might be easier to find out the true compiler name by
something like
case `$CC -v 2>/dev/null` in
*PathScale*) do_something;;
esac
iff `-v' is a valid option to show its version.
Alternatively, but more intensive to maintain, you could look at
Libtool's _LT_CC_BASENAME macro which tries to find out the basename of
the compiler and skip some known wrappers and such. Still, it's not a
very good method, people may have just created different names for them
with symlinks etc. Also note we always match $cc_basename like this:
case $cc_basename in
pathCC*) do_something;;
esac
The trailing * is to allow postfixes, e.g. pathCC-2.2.1.
> Anyway in this particular case, using CXX is certainly more appropriate.
Yes.
Cheers,
Ralf
|
