Build fixes

[nschloe]

This pull request adds project(Albany CXX C Fortran), a command that sets important CMake-internal variables crucial for find_package(). It also enforces proper compiler selection which now has to happen on terminal level when cmake is invoked, e.g.,

CXX=mpicxx \
CC=mpicc \
FC=mpif90 \
cmake \
  ../../source

If the selected compilers don't match the Trilinos compilers, an error is thrown.
With the changes of this PR, find_package(Trilinos REQUIRED) works are expected.

The PR also fixes underlinking in libAlbany and libAlbanySTK (see bug #3).

[ambrad]

Hi Nico,

Could you explain a bit more about the requirement that the compilers be specified in the Albany cmake config line? My understanding is that currently that information is provided by the Trilinos install's TrilinosConfig.cmake. Albany reads that information and sets the compilers accordingly. Hence I think the Albany build's compilers are automatically consistent with the Trilinos ones.

Thanks,
Andrew

[nschloe]

The project() line is needed for getting find_package to work, and one cannot set compilers after project(Albany C CXX Fortran). See Brad King's (one of the core CMake devs) comment from here:

CMAKE__COMPILER should not be set after a language is enabled by the project() or enable_language() command. Normally it should not be set in your CMakeLists.txt code at all.

(One can certainly find a reference in the CMake docs for that, too.) The error-on-compiler-mismatch is the best way I've found dealing with this. See the sample do-configures for Nosh.

[nschloe]

Btw, do we really need C and Fortran compilers here?

[ambrad]

Let's back up a bit. Currently, Albany's CMakeLists.txt does this:

SET(CMAKE_CXX_COMPILER ${Trilinos_CXX_COMPILER} )
SET(CMAKE_C_COMPILER ${Trilinos_C_COMPILER} )
SET(CMAKE_Fortran_COMPILER ${Trilinos_Fortran_COMPILER} )

Then, a few lines later, it issues the project command:

PROJECT(Albany)

Perhaps we could modify this line to

PROJECT(Albany C CXX Fortran)

as you suggest. But I don't see why we can't continue to use the Trilinos_*_COMPILER data. I might be missing something, but the current procedure seems to prevent mismatch errors entirely, and it saves users and tests build scripts from having to manually map Trilinos compilers -> Albany compilers.

[nschloe]

But I don't see why we can't continue use the Trilinos_*_COMPILER data.

project() needs to be set before find_package(), and for some reason you cannot set the compilers in CMake after project().

[ambrad]

Is the requirement that PROJECT be set before FIND_PACKAGE new?

[nschloe]

Not that I knew, and I don't know the details. I vaguely remember having had similar problems once. I'll hit the CMake mailing list to gather some details on this.

[nschloe]

http://public.kitware.com/pipermail/cmake/2015-April/060322.html:
Trilinos installs its export files into lib/<multiarch-tuple> (see http://www.cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html, and option supported by TriBits), so Albany's CMake has to be aware of the architecture before package can be found. The architecture is determined in project().
@ambrad, you might not have experienced this error if you have installed all of Albany's dependencies into architecture-independent directories.

[ambrad]

All,

I'm not going to accept this pull request at this time. Another Albany dev should feel free to do so if desired.

My reasoning is as follows. Nico brings up a good point about Albany's configuration: evidently, Albany won't configure correctly with the PROJECT and FIND_PACKAGE order currently used if Trilinos is configured with -DTrilinos_USE_GNUINSTALLDIRS:BOOL=ON. However, the order that is used allows Albany to determine the compilers used to build the Trilinos installation, thus saving having to specify them again. I prefer to keep this feature.

Additionally, at least at this time, Albany's configuration seems not to be preventing Nico's progress on his modifications to I think Tribits, so I don't feel that there's any immediate need to make a decision on this configuration issue. Again, others should feel free to chime in.

Thanks,
Andrew

[ambrad]

We might introduce an option to distinguish between Nico's preferred build behavior (representing users who want to use the Trilinos_USE_GNUINSTALLDIRS=ON installation configuration) and the current build.

[ambrad]

Changes committed. Nico tested these. Closing this PR. Thanks Nico!