Ralph and Nathan,

As I said, the results I see fail to match the actual ALPS header locations on both CLE4 and CLE5 systems at NERSC.
However, the CLE4 system "just works" because the actual location (/usr/include) gets searched no matter what value configure picks for $orte_check_alps_dir.  I suspect that this is why you didn't see any errors on LANL's system.

Regardless of the defaults, there is still an additional issue with orte_check_alps.m4 that occurs when I give an explicit with-alps=/opt/cray/alps/default in the platform file, which the following bit of config.log confirms:
configure:99227: checking --with-alps value
configure:99247: result: sanity check ok (/opt/cray/alps/default)
configure:99329: checking for alps libraries in "/opt/cray/alps/default/lib64"
configure:99334: result: found


However, when trying to configure the ras:alps component, the value of ras_alps_CPPFLAGS does not contain "-I/opt/cray/alps/default/include" as I would have expected from reading the relevant .m4 files and the generated configure script:
configure:113697: checking for MCA component ras:alps compile mode
configure:113703: result: static
configure:113871: checking alps/apInfo.h usability
configure:113871: gcc -std=gnu99 -c -O3 -DNDEBUG -march=amdfam10 -finline-functions -fno-strict-aliasing -fexceptions -pthread   -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/opal/mca/hwloc/hwloc151/hwloc/include -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/BUILD-edison-gcc/opal/mca/hwloc/hwloc151/hwloc/include -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/opal/mca/event/libevent2019/libevent -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/opal/mca/event/libevent2019/libevent/include -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/BUILD-edison-gcc/opal/mca/event/libevent2019/libevent/include -I/opt/cray/pmi/default/include -I/opt/cray/pmi/default/include -I/opt/cray/pmi/default/include -I/opt/cray/pmi/default/include  conftest.c >&5
conftest.c:640:25: fatal error: alps/apInfo.h: No such file or directory
compilation terminated.
configure:113871: $? = 1

While only 95% certain, I think that this logic in config/orte_check_alps.m4 is to blame:
        if test "$with_alps" = "no" -o -z "$with_alps" ; then
            orte_check_alps_happy="no"
        else
           # Only need to do these tests once (this macro is invoked
           # from multiple different components' configure.m4 scripts

Specifically, the setting of "$1_CPPFLAGS" appears to be ERRONEOUSLY placed within the else-clause of the logic above.  So, when orte/mca/ess/alps/configure.m4 is run BEFORE orte/mca/ras/alps/configure.m4, the variable "with_alps" gets set and the "$1_CPPFLAGS=..." is then unreachable when the ORTE_CHECK_ALPS macro is run later from config/orte_check_alps.m4.

Though it leaves the indentation sloppy, I believe the following might fix the problem, but I lack the autotools versions to test this myself:

--- config/orte_check_alps.m4   (revision 27954)
+++ config/orte_check_alps.m4   (working copy)
@@ -80,6 +80,7 @@
                         [orte_check_alps_dir="/opt/cray/alps/default"],
                         [orte_check_alps_dir="$with_alps"])
            fi
+        fi
 
            $1_CPPFLAGS="-I$orte_check_alps_dir/include"
            $1_LDFLAGS="-L$orte_check_alps_libdir"
@@ -106,7 +107,6 @@
                           AC_MSG_ERROR([Cannot continue])])
                fi
            fi
-        fi
     fi
 
     AS_IF([test "$orte_check_alps_happy" = "yes"], 


-Paul




On Mon, Jan 28, 2013 at 6:30 PM, Ralph Castain <rhc@open-mpi.org> wrote:
Like I said, I didn't write this code - all I can say for certain is that it gets the right answer on the LANL Crays. I'll talk to Nathan (the author) about it tomorrow.

On Jan 28, 2013, at 6:23 PM, Paul Hargrove <phhargrove@lbl.gov> wrote:

Ralph writes
?? It looks correct to me - if with_alps is "yes", then no path was given and we have to look at a default location. If it isn't yes, then a path was given and we use it.
Am I missing something?

Maybe *I* am the one missing something, but the way I read it the following defaults are applied

CLE4:
   orte_check_alps_libdir="/usr/lib/alps"
   orte_check_alps_dir="/opt/cray/alps/default"
CLE5:
   orte_check_alps_libdir="/opt/cray/alps/default/lib64"
   orte_check_alps_dir="/usr"

Unless I am mistaken, the defaults for orte_check_alps_dir should be exchanged to yield:

CLE4:
   orte_check_alps_libdir="/usr/lib/alps"
   orte_check_alps_dir="/usr"
CLE5:
   orte_check_alps_libdir="/opt/cray/alps/default/lib64"
   orte_check_alps_dir="/opt/cray/alps/default"

-Paul


On Mon, Jan 28, 2013 at 6:14 PM, Ralph Castain <rhc@open-mpi.org> wrote:

On Jan 28, 2013, at 6:10 PM, Paul Hargrove <phhargrove@lbl.gov> wrote:

The following 2 fragment from config/orte_check_alps.m4 appear to be contradictory.
By that I mean the first appears to mean that "--with-alps" with no argument means /opt/cray/alps/default/... for CLE5 and /usr/... for CLE4, while the second fragment appears to be doing the opposite:

                   if test "$using_cle5_install" = "yes"; then
                       orte_check_alps_libdir="/opt/cray/alps/default/lib64"
                   else
                       orte_check_alps_libdir="/usr/lib/alps"
                   fi


           if test "$using_cle5_install" = "yes" ; then
                  AS_IF([test "$with_alps" = "yes"],
                        [orte_check_alps_dir="/usr"],
                        [orte_check_alps_dir="$with_alps"])
           else   
                  AS_IF([test "$with_alps" = "yes"],
                        [orte_check_alps_dir="/opt/cray/alps/default"],
                        [orte_check_alps_dir="$with_alps"])
           fi

At least based on header and lib locations on NERSC's XC30 (CLE 5.0.15) and XE6 (CLE 4.1.40), the first fragment is correctwhile the second fragment is "backwards" (the two calls to AS_IF should be exchanged, or the initial "test" should be inverted).

?? It looks correct to me - if with_alps is "yes", then no path was given and we have to look at a default location. If it isn't yes, then a path was given and we use it.

Am I missing something?


Note this same logic is present in both trunk and v1.7 (in SVN - I am not looking at tarballs this time).

-Paul






--
Paul H. Hargrove                          PHHargrove@lbl.gov
Future Technologies Group
Computer and Data Sciences 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


_______________________________________________
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
Computer and Data Sciences 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


_______________________________________________
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
Computer and Data Sciences Department     Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900