search

jedbrown / cmake-modules

CMake modules for some scientific libraries
BSD 2-Clause "Simplified" License
87 stars 54 forks source link

use PATHS instead of HINTS in ResolveCompilerPaths #15

Closed alexfikl closed 8 years ago

alexfikl commented 8 years ago

For some reason, cmake finds the system library instead of the library specified from -L/path/to/lib when using HINTS, but it works fine with PATHS.

This is probably some recent change in behavior (using the very recent cmake 3.5.2), because it used to work just fine. The docs say that PATHS should be used for hardcoded paths, which I guess the command-line flags sort of are, so this should be more correct in any case.

jedbrown commented 8 years ago

Search the paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found.

How is this not what we're doing? These paths are very much dynamically computed. We're finding a command line by system introspection (e.g., finding PETSc makefiles) and decoding it to provide HINTS.

I'm not opposed to merging this provided it works with older CMake, but I'm afraid we need to report it to CMake and document their response so a developer in the future can make sense of willfully misusing the API and possibly causing breakage.

alexfikl commented 8 years ago

I can test it with older CMake, if you want. How old should it be?

I'll also try to reproduce my problem with a smaller example, maybe the problem is related to how I compiled / installed PETSc and not so much with CMake. This could be related as well.

jedbrown commented 8 years ago

2.6 or 2.8 series. Does adding NO_DEFAULT_PATH work? I'd perhaps rather make two calls, one with NO_DEFAULT_PATH and if that fails, another with no HINTS or PATHS. But that thread makes it sound like HINTS is searched in reverse order when NO_DEFAULT_PATH, which if true, must be a bug. CMake is not my favorite...

alexfikl commented 8 years ago

I started testing it with 2.8 and I think I found the problem.

It's not at all with the buildsystem, it's the way I'm compiling PETSc. It seems /usr/lib gets added to the directory list because I compiled PETSc with --with-lapack-lib=/usr/lib/liblapack.so and so a -Wl,-rpath,/usr/lib gets added to the command-line flags and is parsed in ResolveCompilerPaths.

You can close the pull request. Sorry for the noise!

jedbrown commented 8 years ago

Yeah, this is stupid but difficult to handle reliably on PETSc's side. FWIW, that liblapack.so should be discovered automatically. Are you using petsc-3.7? Anyway, thanks for the PR, but I'll close on your recommendation.

alexfikl commented 8 years ago

I'm using PETSc 3.7, but I was using a script written for a cluster that had a custom path for lapack initially, so I simply modified it. The lines are removed now and everything works perfectly.

Thanks!