[CMake] Plural includes, pre-2.6.1 alternative to HINTS, persistence, C99

Jed Brown jed at 59A2.org
Tue Nov 4 14:25:02 EST 2008


(Sorry this is so long.)

I have seen recommendations in CMake documentation to use
FOO_INCLUDE_DIR, FOO_INCLUDE_DIRS, FOO_INCLUDE_PATH, FOO_INCLUDES.
Which is preferred?  The modules included with CMake 2.6.3rc1 are
extremely inconsistent on this.



PETSc provides a common interface to lots of other parallel numerics
packages so linking against PETSc often means linking against around 40
libraries in different locations.  A PETSc installation includes a
makefile, to be included in user projects, which provides the necessary
include and linking variables.  To get this into CMake, I create a
temporary Makefile to extract the include and link lines.  I'm parsing
the link line and for each -L/path/to/lib in the line, I prepend this
path to a list of hint directories, while for each -lsomelib I call
find_library with the appropriate hints.  This relies on CMake looking
at HINTS in order before system files.  While 2.6.1+ does this
correctly, 2.6.0 does not, which caused me a significant headache.
Contrary to the documentation, system paths are searched *before* PATHS,
so I seem to be forced to require at least 2.6.1 (to get HINTS) which is
not yet included in popular distributions such as the latest Ubuntu
08.10).

The FindMPI module does similar parsing of linker flags, but it's
actually incorrect since it adds a list of all library paths and then
tries to find individual libraries.  It will fail if the MPI compilers
flags have something like

  -L/A -la -L/B -lb

which will mistakenly resolve to "/A/liba.so;/A/libb.so" if /A/libb.so
exists.  It would be great to have this sort of parsing in a module.
Could someone have a look at what I'm doing here

  http://github.com/jedbrown/cmake-modules/tree/master/FindPETSc.cmake#L126

and let me know if there is a better way to do it.  BTW, I'm happy to
maintain these modules:

  http://github.com/jedbrown/cmake-modules



Note that the FindiMesh module (in the repo above) also needs to write a
temporary Makefile to pull out the relevant flags and parse that.  I
think the logic of poking a temporary Makefile should be put in a
separate module, but I don't know how to write it.  Also, both of these
modules are stateful in that the user can set some environment variables
or define CMake variables to tell the module where to look for the
package and only if these variables are changed on a subsequent CMake
run will module will regenerate the configuration.  That is, users
normally set PETSC_DIR and PETSC_ARCH, from which the module can find
the package.  The required libraries, flags, etc are marked as advanced
and put in cache.  If the user only edits these advanced values, a
reconfigure won't blast them, but if the user edits PETSC_DIR or
PETSC_ARCH, then reconfigure will replace the advanced entries.  FindMPI
has a poor-man's version of this where the user needs to also manually
set MPI_LIBRARY to NOTFOUND which is ugly and unintuitive.  Am I doing
it wrong?  If not, this pattern should really be abstracted out, it's
ugly to keep duplicating it.

What's with the recommendation that XXX_LIBRARIES and similar should not
be a cache entry while find_package_handle_standard_args() puts them in
cache, albeit marked as advanced?  Is advanced considered "not a cache
entry"?



How does CMake handle order-dependence in lists of libraries?  On my
platform, it looks like it just passes the whole list to the linker
twice so that order doesn't matter, but then it could always remove
duplicates.  It doesn't so why not?  It would make the link line
shorter, hence easier to spot errors.




How does one find a C99 compiler?  For GNU and PGI compilers, we can use

  set (CMAKE_C_FLAGS -std=c99)

but this is not portable and becomes a very ugly hack if part of your
source is C99 and part of it is C90.  I think we really need to be able
to set a default LANGUAGE (or DIALECT) property and then override for
other files using set_source_files_properties.


Jed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20081104/fde7c877/attachment.pgp>


More information about the CMake mailing list