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