Bug 15823

Correction: GCC _when compiled as a cross-compiler_ does not ship a working executable named "cpp".  I inadvertently left out that caveat.

(In reply to Brooks Moses from comment #0)
> It would be notably better if we could simply provide a true cpp executable
> name to rpcgen directly.  I note that there is not even any apparent benefit
> to having the user specify a directory rather than a complete path to the
> executable; the path is used for nothing else.

Agreed. I'd accept a patch that does that.

On Thu, 8 Aug 2013, brooks at gcc dot gnu.org wrote:

> However, we find that, due to
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955, GCC does not ship a working
> executable named "cpp" -- and has not for many years.  (The bug is that GCC's
> $target/bin/cpp is broken; only bin/$target-cpp works.)

I'd say the bug is installing the files in $target/bin/ at all.

(In reply to joseph@codesourcery.com from comment #3)
> On Thu, 8 Aug 2013, brooks at gcc dot gnu.org wrote:
> 
> > However, we find that, due to
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955, GCC does not ship a working
> > executable named "cpp" -- and has not for many years.  (The bug is that GCC's
> > $target/bin/cpp is broken; only bin/$target-cpp works.)
> 
> I'd say the bug is installing the files in $target/bin/ at all.

Which is orthogonal to the enhancement of allowing the user to select the cpp executable to use when running rpcgen.

(In reply to joseph@codesourcery.com from comment #3)
> The bug is that GCC's $target/bin/cpp is broken; only bin/$target-cpp works.
> 
> I'd say the bug is installing the files in $target/bin/ at all.

I.e., that there should only be bin/$target-gcc and so forth?

The fun thing there, of course, is that if you remove things like $target/bin/as, then GCC doesn't know where to find an assembler unless you explicitly point it at bin/$target-as.  Which is arguably just more of the same bug.

Anyway, an interesting suggestion, if you want to post it into the GCC bug report, and I'd be awfully tempted to implement it.

I mildly disagree with Carlos; it is not _entirely_ orthogonal so much as reinforcing the point that the right fix is the proposed enhancement, rather than "just go fix the GCC bug".  But I mildly disagree with him only in the spirit of agreeing with him that it's off-topic.  :)

(In reply to Brooks Moses from comment #5)
> I mildly disagree with Carlos; it is not _entirely_ orthogonal so much as
> reinforcing the point that the right fix is the proposed enhancement, rather
> than "just go fix the GCC bug".  But I mildly disagree with him only in the
> spirit of agreeing with him that it's off-topic.  :)

I mildly disagree with your mild disagreement.

(In reply to joseph@codesourcery.com from comment #3)
> I'd say the bug is installing the files in $target/bin/ at all.

Interestingly, GCC does that only if $target/bin exists.  It doesn't create that directory on its own.

(In reply to Brooks Moses from comment #5)
> The fun thing there, of course, is that if you remove things like
> $target/bin/as, then GCC doesn't know where to find an assembler unless you
> explicitly point it at bin/$target-as.  Which is arguably just more of the
> same bug.

This is not a bug, since GCC has been configured to use $target/bin/as (which isn't part of GCC), so if you remove it it will of course break.  If you reconfigure GCC to use bin/$target-as it will be happy to use that.

On Thu, 8 Aug 2013, brooks at gcc dot gnu.org wrote:

> http://sourceware.org/bugzilla/show_bug.cgi?id=15823
> 
> --- Comment #5 from Brooks Moses <brooks at gcc dot gnu.org> ---
> (In reply to joseph@codesourcery.com from comment #3)
> > The bug is that GCC's $target/bin/cpp is broken; only bin/$target-cpp works.
> > 
> > I'd say the bug is installing the files in $target/bin/ at all.
> 
> I.e., that there should only be bin/$target-gcc and so forth?

Yes.  That directory contains executables from binutils for internal use 
by GCC; that's its sole purpose.  The files installed by GCC there aren't 
used by GCC (rather, the public installed copy of the driver gets used 
when collect2 needs to call back to the driver), so shouldn't be 
installed.

Back on topic: Any opinions or guidance for what flag letter to use for an option that specifies the CPP executable?

The already-used list is abchiklmnostCDIKLMNSTY5, so what's left is defgjpqruvwxyzABEFGHJOPQRUVWXZ.

The -Y option seems like it was just a random spare letter, which suggests -X or -Z for similar reasons.

(In reply to Brooks Moses from comment #9)
> Back on topic: Any opinions or guidance for what flag letter to use for an
> option that specifies the CPP executable?
> 
> The already-used list is abchiklmnostCDIKLMNSTY5, so what's left is
> defgjpqruvwxyzABEFGHJOPQRUVWXZ.
> 
> The -Y option seems like it was just a random spare letter, which suggests
> -X or -Z for similar reasons.

Bikeshed.

what if we changed -Y behavior:
- stat the input arg
- if it's a dir, append "/cpp" automatically like we do today
- if it's a file, use the value unmodified
- throw an error otherwise
- update or delete find_cpp logic

there is the question of how do we pass down CPPFLAGS.  we could add an explicit flag like -y, or we could further extend the -Y behavior so that, instead of throwing an error, we split on whitespace.