That is truly bizarre "make" behavior. 

Heads up that in the upcoming fortran revamp, we *only* use FC. I.E., there's only mpifort wrapper compiler (mpif77 and mpif90 still exist, but only as sym links to mpifort, signifying that mpifort is the way of the future). 

This was done because there have been no f77 compilers for decades (literally), and no f90 compilers for 10+ years. All the fortran compiler vendors have long-since moved to a single compiler executable name (e.g., ifort, gfortran), so mpifort just reflects that. 

Sent from my phone. No type good. 

On Feb 21, 2012, at 5:01 AM, "Paul H. Hargrove" <PHHargrove@lbl.gov> wrote:

Thanks, Ralph.
Excellent point about not needing to use the "FC" name with its special (absurd?) behavior.

-Paul

On 2/21/2012 1:52 AM, Ralph Castain wrote:
I went ahead and applied this, with a tweak. There is no reason to call our flag "FC" as all we use it for is to call the write wrapper. So I renamed it to something less problematic.

On Feb 21, 2012, at 1:20 AM, Paul H. Hargrove wrote:

And while we are looking at examples/Makefile on Solaris-10, why are the F77 examples getting built w/ mpif90?
Because w/ the Solaris make setting FC also silently sets F77 (yes, I am NOT kidding)!
So, reordering the F77= and FC= lines in Makefile resolves that mis-behavior.

Attached is my patch to fix both F77/FC and the "better" ompi_info queries mentioned in my previous post.
This REPLACES the patch in the previous post.

-Paul

On 2/20/2012 11:36 PM, Paul H. Hargrove wrote:
The addition on Monday of the Java cases to examples/Makefile has shown that the default "make" in Solaris-10 will stop on the first failed grep command in the "all" rule:
$ make
mpicc -g   -o hello_c hello_c.c
mpicc -g   -o ring_c ring_c.c
mpicc -g   -o connectivity_c connectivity_c.c
mpic++ -g   -o hello_cxx hello_cxx.cc
mpic++ -g   -o ring_cxx ring_cxx.cc
mpif90 -g hello_f77.f -o hello_f77
mpif90 -g ring_f77.f -o ring_f77
mpif90 -g hello_f90.f90 -o hello_f90
mpif90 -g ring_f90.f90 -o ring_f90
*** Error code 1
The following command caused the error:
if test "`ompi_info --parsable | grep bindings:java:yes`" != ""; then \
    make Hello.class; \
fi
make: Fatal error: Command failed for target `all'

The addition of java did NOT break anything, but exposed a pre-existing problem which  was not evident in my prior testing because all language bindings were being build prior to adding java.

The attached patch resolves the problem in my (admittedly minimal) testing with the smallest possible change.
However an entirely different avoids both "test" and "true" and simply looks like:
    @ if ompi_info --parsable | grep bindings:cxx:yes >/dev/null; then
I have *also* tested that approach, and it works fine too.

I *did* warn that the introduction of the java bindings would bring collateral damage.
I just didn't anticipate encountering it personally.

-Paul



_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

-- 
Paul H. Hargrove                          PHHargrove@lbl.gov
Future Technologies Group
HPC Research Department                   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900
<example_makefile.diff2>_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

-- 
Paul H. Hargrove                          PHHargrove@lbl.gov
Future Technologies Group
HPC Research Department                   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900
_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel