#12 Allow specification of path for external libs, etc

None
closed
nobody
None
5
2014-01-15
2012-04-16
Tom Payerle
No

I am running into issues building plplot because some requirements for desired bindings are in non-standard locations on my systems. E.g., python on my systems is python2.4, with relatively limited add on modules, and python2.6 is the less old v2.6 with more modules which I want to have plplot
use. (Yes, I should make python2.6, or better 2.8 the default, but that is a different kettle of fish).

I have seen other people having similar issues (e.g. http://cmake.3232098.n2.nabble.com/CMAKE-LIBRARY-PATH-appears-not-to-work-properly-for-finding-libtcl-tt5044674.html#a5066554\)

I have not looked at the Find_XXX code, but will concede that it is doing complicated stuff, and while what it does is wrong for some purposes , it is not clear that it is always (or even mostly) wrong. And changing its behaviour, even if correct for some purposes, might foul up other uses.

Is it possible to just add addition CMake variables so the person compiling can specify exactly which perl, tcl, assorted libraries, etc they wish to
use for the build. If nothing specified, go with the assorted Find_XXX routines, which are fine for the most general cases, but allow me to override
when I know the Find_XXX routines are not getting good results in my environment. It's a fair number of variables to add, but should mostly be
pretty simple, and allow for lots of flexibility w/out making it harder for users in the more normal cases.

Discussion

  • Alan W. Irwin
    Alan W. Irwin
    2014-01-15

    • status: open --> closed
    • Group: -->
     
  • Alan W. Irwin
    Alan W. Irwin
    2014-01-15

    In general, as discussed in the thread you referred to, CMake uses an outer and inner loop for each find process. In general, the outer loop is over alternative names and versions generally starting with the latest version, and the inner loop is over the superpath specified by the PATH, CMAKE_LIBRARY_PATH, etc. environment variables. So regardless of how the user manipulates the superpath, CMake still tends to find the latest version of all libraries. CMake developers have recently introduced the NAMES_PER_DIR option for find_library that switches the outer and inner loops and gives much more user control via the superpath over what version is found. But other CMake find commands do not (yet) have such options, and it will be a long time before the use of such options will propagate to the find modules.

    That said, when superpath methods fail (generally because the desired library version in a non-standard location is an older version than the system version), there are also idosyncratic variables you can set to force CMake to find the desired library version, i.e., the variables you ask for already exist. So I am going to close this as a feature request since those features already exist. That does leave the problem of discovering the names of the variables you have to set, but a question to the plplot-general list should normally provide that answer (if you give enough details of the name and location of the library that you want CMake to find).