(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
pgp76wT1iGJlD.pgp
Description: PGP signature
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
