bug#8880: [PATCH] add pgcc support to depcomp

[Dave Goodell]

On Feb 25, 2012, at 3:08 AM CST, Stefano Lattarini wrote:

> On 02/25/2012 03:22 AM, Dave Goodell wrote:
>> Portland Group C Compiler support based on a code from Jeff Daily @ PNNL
>> via the automake list and automake bug #8880:
>> 
> By a very cursory look, this patch seems safe and unobtrusive (it shouldn't
> influence the existing depmodes at all, so basically no room for regression).
> So I'd love to apply the patch before the next Automake release (1.12).

I'm glad to hear that.

> I also assume you've re-run the whole automake testsuite after applying
> this patch (to master), *using the Portland C compilers*, and seen no
> failure, right?  If you haven't, here is how you can do that (from a
> *clean* automake checkout with your patch applied):

This is done now.  Regrettably it didn't occur to me to try this when I was 
submitting the patch originally.  I'll send an updated patch in a moment that 
passes all of the tests (modulo SKIPs, XFAILs, and the two tests mentioned 
below) with pgcc 10.5-0 on a 64-bit Ubuntu 10.04.4 LTS installation.  There 
were a couple of small failures in the old version related to distcleancheck 
that were easy to fix.

"silent-many-generic" fails with or without this patch.  It requires a code fix 
to be stricter about the grep pattern ("pgCC " matches /CC /).  One must also 
run it with "LIBS=-pgf90libs" to get success.  Automake's linker selection 
heuristic chooses CXXLD for linking C++ with Fortran code, but that is 
insufficient for the PGI compilers in this situation.  I'll send a separate 
patch to automake-patches@ that fixes the first issue.  The latter issue is way 
out of scope for me.

"yacc-dist-nobuild.dir" fails without this depcomp patch, but it passes with 
it.  I didn't fully grok this test, but it looks like the test requires 
dependency support from the compiler+depcomp to operate correctly.  I don't 
have time to investigate this thoroughly, but you can reproduce it with GCC by 
running this test with "am_cv_CC_dependencies_compiler_type=none" set in the 
environment.

> we'll need a proper disclaimer from *all* the people who have written this
> code before incorporating it in the automake repository.  So I ask:
> 
>  Would you and the other people that have written this code be willing
>  to assign the copyright to the Free Software Foundation, so that we
>  could install it in package?
> 
> or, this is not possible or undesired for some reason,
> 
>  Would you and the other people that have written this code be willing
>  to sign a copyright disclaimer to put this change in the public domain,
>  so that we can install it in package?

Either option is fine with me, with a slight preference towards the latter.  If 
one or the other is more compatible with Jeff's situation, then we can do that.

-Dave