should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Mario Emmenlauer

Dear All,

I use find_package(ZLIB) to detect zlib on Ubuntu 16.04 Linux.
I have a newer zlib in /data/thirdparty that I'd like to use. To
prefer my newer version I add -DCMAKE_PREFIX_PATH="/data/thirdparty".
In my understanding, the documentation says CMAKE_PREFIX_PATH is
searched first (1). But cmake behaves different than I'd expect:

It detects the system zlib first:

-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8")

And then complains that zlib exists twice:

CMake Warning at CMakeLists.txt:693 (add_library):
  Cannot generate a safe runtime search path for target bdaimage because
  files in some directories may conflict with libraries in implicit
  directories:
    runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /data/thirdparty/lib
  Some of these libraries may not be found correctly.

Why am I misunderstanding the documentation? Is CMAKE_PREFIX_PATH
not preferred over system directories?

All the best,

    Mario Emmenlauer


(1) https://cmake.org/cmake/help/v3.0/command/find_package.html



--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Stephen McDowell
Hi Mario,

Do you get different results if you set CMAKE_MODULE_PATH rather than CMAKE_PREFIX_PATH?  I wrote a tutorial for how to install a library called librealsense, at the very bottom is what will interest you:


    # Allow for `find_package(realsense2)` in CMake projects
    export CMAKE_MODULE_PATH="/opt/librealsense/lib/cmake${CMAKE_MODULE_PATH:+:${CMAKE_MODULE_PATH}}"

This environment variable can either be set, or specified like you are doing with cmake .. -DCMAKE_MODULE_PATH=“/data/thirdparty”, noting that depending on where it got installed you may also need an extra lib on that path

    /data/thirdparty/lib

I’m sure others on this list know the “right” practice, but when CMAKE_INSTALL_PREFIX=/usr/local, it’s very common to see two possible install locations:

    /usr/local/cmake
    /usr/local/lib/cmake

AKA just make sure that the zlib folder is a child directory.  In the librealsense2 example, I have

    $ ls /opt/librealsense2/lib/cmake/
    realsense2/

So since /opt/librealsense2/lib/cmake is in my CMAKE_MODULE_PATH, when I do find_package(realsense2), it will find that directory.

I don’t know exactly what Zlib’s install looks like, and I know it matters whether they are using “new” or “old” cmake installation tactics, but hopefully this gets you closer to solving it!

-Stephen


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Mario Emmenlauer

Dear Stephen,

thanks for your great help, I certainly learned something! But for
my current problem, zlib generally uses autotools to build, and the
find_package(ZLIB) is in my case looking for the library, not the
cmake config. Would your idea of CMAKE_MODULE_PATH apply to that?

All the best,

   Mario


On 21.03.2018 20:12, Stephen McDowell wrote:

> Hi Mario,
>
> Do you get different results if you set CMAKE_MODULE_PATH rather than CMAKE_PREFIX_PATH?  I wrote a tutorial for how to install a library called librealsense,
> at the very bottom is what will interest you:
>
> https://gist.github.com/svenevs/f00ed3898d2af6248921b63254aa8cc1#enable-librealsense-for-other-cmake-projects
>
> # Allow for `find_package(realsense2)` in CMake projects
> export CMAKE_MODULE_PATH="/opt/librealsense/lib/cmake${CMAKE_MODULE_PATH:+:${CMAKE_MODULE_PATH}}"
>
>
> This environment variable can either be set, or specified like you are doing with cmake .. -DCMAKE_MODULE_PATH=“/data/thirdparty”, *noting* that depending on
> where it got installed you may also need an extra *lib* on that path
>
>     /data/thirdparty/*lib*
> *
> *
> I’m sure others on this list know the “right” practice, but when CMAKE_INSTALL_PREFIX=/usr/local, it’s very common to see two possible install locations:
>
>     /usr/local/cmake
>     /usr/local/lib/cmake
>
> AKA just make sure that the zlib folder is a child directory.  In the librealsense2 example, I have
>
>     $ ls /opt/librealsense2/lib/cmake/
>     realsense2/
>
> So since /opt/librealsense2/lib/cmake is in my CMAKE_MODULE_PATH, when I do find_package(realsense2), it will find that directory.
>
> I don’t know exactly what Zlib’s install looks like, and I know it matters whether they are using “new” or “old” cmake installation tactics, but hopefully this
> gets you closer to solving it!
>
> -Stephen
>
>
>



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Stephen McDowell
Hi Mario,

Very sorry, I should have looked more closely!  CMAKE_MODULE_PATH is for libraries that install their own CMake scripts.  You are correct, Zlib only installs a pkg-config script.  However, FindZLIB.cmake doesn’t appear to use that at all (aka I don’t believe you need to be setting PKG_CONFIG_PATH).  You should be able to get away with setting ZLIB_ROOT.  So for you I think it would look like

    cmake .. -DZLIB_ROOT=/data/thirdparty

FindZLIB.cmake will proceed to look for ZLIB_ROOT/include/zlib.h and look in ZLIB_ROOT/lib for the library.

The XXX_ROOT is typically available for any built-in CMake FindXXX.cmake modules (see hint at bottom: https://cmake.org/cmake/help/v3.0/module/FindZLIB.html ).  These FindXXX.cmake modules are for this exact scenario: there is a library that many users want access to that does not install cmake scripts (typically because the library uses a different build system such as autotools).

- - - - -

If you are still having trouble, this is what I used to test this.  I didn’t actually write code that uses it, but I suspect if you remove setting of CMAKE_PREFIX_PATH (I think that’s where your conflict originates from) and just specify ZLIB_ROOT your problem will be solved (I hope!).

With a very crude CMakeLists.txt:

    cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
    project("find_zlib")

    find_package(ZLIB)
    if (ZLIB_FOUND)
      message(FATAL_ERROR "Found Zlib:\n- ZLIB_INCLUDE_DIRS: ${ZLIB_INCLUDE_DIRS}\n- ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}")
    else()
      message(FATAL_ERROR "Did not find Zlib :/")
    endif()

Without setting ZLIB_ROOT:

    $ cmake ..
    -- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8")
    CMake Error at CMakeLists.txt:6 (message):
      Found Zlib:
      - ZLIB_INCLUDE_DIRS: /usr/include
      - ZLIB_LIBRARIES: /usr/lib/libz.dylib

That’s the default Zlib that comes with OS X.  However, if I specify ZLIB_ROOT:

    $ cmake .. -DZLIB_ROOT=/usr/local/Cellar/zlib/1.2.11/
    -- Found ZLIB: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib (found version "1.2.11")
    CMake Error at CMakeLists.txt:6 (message):
      Found Zlib:
      - ZLIB_INCLUDE_DIRS: /usr/local/Cellar/zlib/1.2.11/include
      - ZLIB_LIBRARIES: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib

Let us know if it works or if you still need help!

-Stephen


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Mario Emmenlauer

Dear Stephen,

thanks a lot for your support! I've tested and your suggestion works!

But, it does not fully resolve my pain :-( I'm slightly scared now
because I assumed that cmake would prefer CMAKE_PREFIX_PATH over system
libraries. In my understanding, the documentation says CMAKE_PREFIX_PATH
is searched first (1). That aspect is quite crucial to me, because I have
patched versions of more than 30 standard libraries in CMAKE_PREFIX_PATH.
If I can not rely that cmake would use the patched versions, then I
may end up having an "interesting" mix of system and patched libraries
in my executable :-(

(1) https://cmake.org/cmake/help/v3.0/command/find_package.html

Thanks a lot and all the best,

    Mario


On 22.03.2018 17:43, Stephen McDowell wrote:

> Hi Mario,
>
> Very sorry, I should have looked more closely!  CMAKE_MODULE_PATH is for libraries that install their own CMake scripts.  You are correct, Zlib only installs a
> pkg-config script.  However, FindZLIB.cmake doesn’t appear to use that at all (aka I don’t believe you /need/ to be setting PKG_CONFIG_PATH).  You should be
> able to get away with setting *ZLIB_ROOT*.  So for you I think it would look like
>
>     cmake .. -DZLIB_ROOT=/data/thirdparty
>
> FindZLIB.cmake will proceed to look for ZLIB_ROOT/include/zlib.h and look in ZLIB_ROOT/lib for the library.
>
> The XXX_ROOT is typically available for any built-in CMake FindXXX.cmake modules (see hint at bottom: https://cmake.org/cmake/help/v3.0/module/FindZLIB.html ).
>  These FindXXX.cmake modules are for this exact scenario: there is a library that many users want access to that does not install cmake scripts (typically
> because the library uses a different build system such as autotools).
>
> - - - - -
>
> If you are still having trouble, this is what I used to test this.  I didn’t actually write code that uses it, but I suspect if you *remove* setting of
> CMAKE_PREFIX_PATH (I think that’s where your conflict originates from) and just specify ZLIB_ROOT your problem will be solved (I hope!).
>
> With a very crude CMakeLists.txt:
>
>     cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
>     project("find_zlib")
>
>     find_package(ZLIB)
>     if (ZLIB_FOUND)
>       message(FATAL_ERROR "Found Zlib:\n- ZLIB_INCLUDE_DIRS: ${ZLIB_INCLUDE_DIRS}\n- ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}")
>     else()
>       message(FATAL_ERROR "Did not find Zlib :/")
>     endif()
>
> *Without* setting ZLIB_ROOT:
>
>     $ cmake ..
>     -- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8")
>     CMake Error at CMakeLists.txt:6 (message):
>       Found Zlib:
>       - ZLIB_INCLUDE_DIRS: /usr/include
>       - ZLIB_LIBRARIES: /usr/lib/libz.dylib
>
> That’s the default Zlib that comes with OS X.  However, if I specify ZLIB_ROOT:
>
>     $ cmake .. -DZLIB_ROOT=/usr/local/Cellar/zlib/1.2.11/
>     -- Found ZLIB: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib (found version "1.2.11")
>     CMake Error at CMakeLists.txt:6 (message):
>       Found Zlib:
>       - ZLIB_INCLUDE_DIRS: /usr/local/Cellar/zlib/1.2.11/include
>       - ZLIB_LIBRARIES: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib
>
> Let us know if it works or if you still need help!
>
> -Stephen
>
>
>


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Stephen McDowell
That’s progress though? :)

Hmmm.  I understand your problem now, but I don’t know how to fix it.  You can do things like

   find_package(ZLIB NO_DEFAULT_PATH)

That makes it so the system Zlib won’t be found, but I couldn’t then get `cmake .. -DZLIB_ROOT=xxx` to work :/  There are other NO_* variables mentioned on that page too, maybe one of those and setting CMAKE_PREFIX_PATH could work?  I’m not familiar with these path variables in CMake…

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

CMake mailing list
In reply to this post by Mario Emmenlauer
Are you setting `CMAKE_INSTALL_PREFIX`? This path is searched before the `CMAKE_PREFIX_PATH` is searched. 

Also the find_package paths listed in the documentation are only for libraries that provide find_package support. Zlib does not, so it cmake fallsback on the FindZLIB.cmake module to do the searching which the search order can be entirely up to the author of the module. You can see how FindZLIB.cmake searches here:


Of course, if its not correctly searching the `CMAKE_PREFIX_PATH` then this should be considered a bug.

On Mar 22, 2018, at 11:54 AM, Mario Emmenlauer <[hidden email]> wrote:


Dear Stephen,

thanks a lot for your support! I've tested and your suggestion works!

But, it does not fully resolve my pain :-( I'm slightly scared now
because I assumed that cmake would prefer CMAKE_PREFIX_PATH over system
libraries. In my understanding, the documentation says CMAKE_PREFIX_PATH
is searched first (1). That aspect is quite crucial to me, because I have
patched versions of more than 30 standard libraries in CMAKE_PREFIX_PATH.
If I can not rely that cmake would use the patched versions, then I
may end up having an "interesting" mix of system and patched libraries
in my executable :-(

(1) https://cmake.org/cmake/help/v3.0/command/find_package.html

Thanks a lot and all the best,

   Mario


On 22.03.2018 17:43, Stephen McDowell wrote:
Hi Mario,

Very sorry, I should have looked more closely!  CMAKE_MODULE_PATH is for libraries that install their own CMake scripts.  You are correct, Zlib only installs a
pkg-config script.  However, FindZLIB.cmake doesn’t appear to use that at all (aka I don’t believe you /need/ to be setting PKG_CONFIG_PATH).  You should be
able to get away with setting *ZLIB_ROOT*.  So for you I think it would look like

    cmake .. -DZLIB_ROOT=/data/thirdparty

FindZLIB.cmake will proceed to look for ZLIB_ROOT/include/zlib.h and look in ZLIB_ROOT/lib for the library.

The XXX_ROOT is typically available for any built-in CMake FindXXX.cmake modules (see hint at bottom: https://cmake.org/cmake/help/v3.0/module/FindZLIB.html ).
 These FindXXX.cmake modules are for this exact scenario: there is a library that many users want access to that does not install cmake scripts (typically
because the library uses a different build system such as autotools).

- - - - -

If you are still having trouble, this is what I used to test this.  I didn’t actually write code that uses it, but I suspect if you *remove* setting of
CMAKE_PREFIX_PATH (I think that’s where your conflict originates from) and just specify ZLIB_ROOT your problem will be solved (I hope!).

With a very crude CMakeLists.txt:

    cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
    project("find_zlib")

    find_package(ZLIB)
    if (ZLIB_FOUND)
      message(FATAL_ERROR "Found Zlib:\n- ZLIB_INCLUDE_DIRS: ${ZLIB_INCLUDE_DIRS}\n- ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}")
    else()
      message(FATAL_ERROR "Did not find Zlib :/")
    endif()

*Without* setting ZLIB_ROOT:

    $ cmake ..
    -- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8")
    CMake Error at CMakeLists.txt:6 (message):
      Found Zlib:
      - ZLIB_INCLUDE_DIRS: /usr/include
      - ZLIB_LIBRARIES: /usr/lib/libz.dylib

That’s the default Zlib that comes with OS X.  However, if I specify ZLIB_ROOT:

    $ cmake .. -DZLIB_ROOT=/usr/local/Cellar/zlib/1.2.11/
    -- Found ZLIB: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib (found version "1.2.11")
    CMake Error at CMakeLists.txt:6 (message):
      Found Zlib:
      - ZLIB_INCLUDE_DIRS: /usr/local/Cellar/zlib/1.2.11/include
      - ZLIB_LIBRARIES: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib

Let us know if it works or if you still need help!

-Stephen





--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Mario Emmenlauer

Thanks PF, I think this makes more sense now! I was assuming that
cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you
clarified, that only applies to libraries that provide find_package
support.

This is actually quite unfortunate. Then I don't see an easy way to
enforce usage of specific libs. As an example, if I want to enforce a
patched libtiff (that does not itself provide find_package support)
the only "safe" way is to replace the system libtiff. Otherwise any
package might just find the system version first without me even
knowing.

This actually opens quite a can of worms :-(

All the best,

   Mario



On 23.03.2018 00:52, P F wrote:

> Are you setting `CMAKE_INSTALL_PREFIX`? This path is searched before the `CMAKE_PREFIX_PATH` is searched. 
>
> Also the find_package paths listed in the documentation are only for libraries that provide find_package support. Zlib does not, so it cmake fallsback on the
> FindZLIB.cmake module to do the searching which the search order can be entirely up to the author of the module. You can see how FindZLIB.cmake searches here:
>
> https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L72
>
> Of course, if its not correctly searching the `CMAKE_PREFIX_PATH` then this should be considered a bug.
>
>> On Mar 22, 2018, at 11:54 AM, Mario Emmenlauer <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>
>> Dear Stephen,
>>
>> thanks a lot for your support! I've tested and your suggestion works!
>>
>> But, it does not fully resolve my pain :-( I'm slightly scared now
>> because I assumed that cmake would prefer CMAKE_PREFIX_PATH over system
>> libraries. In my understanding, the documentation says CMAKE_PREFIX_PATH
>> is searched first (1). That aspect is quite crucial to me, because I have
>> patched versions of more than 30 standard libraries in CMAKE_PREFIX_PATH.
>> If I can not rely that cmake would use the patched versions, then I
>> may end up having an "interesting" mix of system and patched libraries
>> in my executable :-(
>>
>> (1) https://cmake.org/cmake/help/v3.0/command/find_package.html
>>
>> Thanks a lot and all the best,
>>
>>    Mario
>>
>>
>> On 22.03.2018 17:43, Stephen McDowell wrote:
>>> Hi Mario,
>>>
>>> Very sorry, I should have looked more closely!  CMAKE_MODULE_PATH is for libraries that install their own CMake scripts.  You are correct, Zlib only installs a
>>> pkg-config script.  However, FindZLIB.cmake doesn’t appear to use that at all (aka I don’t believe you /need/ to be setting PKG_CONFIG_PATH).  You should be
>>> able to get away with setting *ZLIB_ROOT*.  So for you I think it would look like
>>>
>>>     cmake .. -DZLIB_ROOT=/data/thirdparty
>>>
>>> FindZLIB.cmake will proceed to look for ZLIB_ROOT/include/zlib.h and look in ZLIB_ROOT/lib for the library.
>>>
>>> The XXX_ROOT is typically available for any built-in CMake FindXXX.cmake modules (see hint at bottom: https://cmake.org/cmake/help/v3.0/module/FindZLIB.html ).
>>>  These FindXXX.cmake modules are for this exact scenario: there is a library that many users want access to that does not install cmake scripts (typically
>>> because the library uses a different build system such as autotools).
>>>
>>> - - - - -
>>>
>>> If you are still having trouble, this is what I used to test this.  I didn’t actually write code that uses it, but I suspect if you *remove* setting of
>>> CMAKE_PREFIX_PATH (I think that’s where your conflict originates from) and just specify ZLIB_ROOT your problem will be solved (I hope!).
>>>
>>> With a very crude CMakeLists.txt:
>>>
>>>     cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
>>>     project("find_zlib")
>>>
>>>     find_package(ZLIB)
>>>     if (ZLIB_FOUND)
>>>       message(FATAL_ERROR "Found Zlib:\n- ZLIB_INCLUDE_DIRS: ${ZLIB_INCLUDE_DIRS}\n- ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}")
>>>     else()
>>>       message(FATAL_ERROR "Did not find Zlib :/")
>>>     endif()
>>>
>>> *Without* setting ZLIB_ROOT:
>>>
>>>     $ cmake ..
>>>     -- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8")
>>>     CMake Error at CMakeLists.txt:6 (message):
>>>       Found Zlib:
>>>       - ZLIB_INCLUDE_DIRS: /usr/include
>>>       - ZLIB_LIBRARIES: /usr/lib/libz.dylib
>>>
>>> That’s the default Zlib that comes with OS X.  However, if I specify ZLIB_ROOT:
>>>
>>>     $ cmake .. -DZLIB_ROOT=/usr/local/Cellar/zlib/1.2.11/
>>>     -- Found ZLIB: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib (found version "1.2.11")
>>>     CMake Error at CMakeLists.txt:6 (message):
>>>       Found Zlib:
>>>       - ZLIB_INCLUDE_DIRS: /usr/local/Cellar/zlib/1.2.11/include
>>>       - ZLIB_LIBRARIES: /usr/local/Cellar/zlib/1.2.11/lib/libz.dylib
>>>
>>> Let us know if it works or if you still need help!
>>>
>>> -Stephen



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Eric Noulard


2018-03-23 10:21 GMT+01:00 Mario Emmenlauer <[hidden email]>:

Thanks PF, I think this makes more sense now! I was assuming that
cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you
clarified, that only applies to libraries that provide find_package
support.

This is actually quite unfortunate. Then I don't see an easy way to
enforce usage of specific libs. As an example, if I want to enforce a
patched libtiff (that does not itself provide find_package support)
the only "safe" way is to replace the system libtiff. Otherwise any
package might just find the system version first without me even
knowing.

You can always ship your own/patched version of  Find<Whatever>.cmake module with your
project source and build the 'local' override logic in it for every project/lib that does not provide a find_package.

Be sure to APPEND your local cmake module path (CMAKE_MODULE_PATH)

something like:
 list(APPEND CMAKE_MODULE_PATH ${AFS_SOURCE_DIR}/cmake)

before using find_package etc...

I find it a "safer" solution than system lib replacement.
My opinion though.

--
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Mario Emmenlauer

Hi Eric,

On 23.03.2018 10:58, Eric Noulard wrote:

> 2018-03-23 10:21 GMT+01:00 Mario Emmenlauer <[hidden email] <mailto:[hidden email]>>:
>
>
>     Thanks PF, I think this makes more sense now! I was assuming that
>     cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you
>     clarified, that only applies to libraries that provide find_package
>     support.
>
>     This is actually quite unfortunate. Then I don't see an easy way to
>     enforce usage of specific libs. As an example, if I want to enforce a
>     patched libtiff (that does not itself provide find_package support)
>     the only "safe" way is to replace the system libtiff. Otherwise any
>     package might just find the system version first without me even
>     knowing.
>
>
> You can always ship your own/patched version of  Find<Whatever>.cmake module with your
> project source and build the 'local' override logic in it for every project/lib that does not provide a find_package.
>
> Be sure to APPEND your local cmake module path (CMAKE_MODULE_PATH)
>
> something like:
>  list(APPEND CMAKE_MODULE_PATH ${AFS_SOURCE_DIR}/cmake)
>
> before using find_package etc...
>
> I find it a "safer" solution than system lib replacement.
> My opinion though.

I was considering this option too. But in my original email I outlined
that this is not only for my own package, but additionally for more than
30 thirdparty dependencies. So its not only about ensuring that my
packages use the correct thirdparty version, furthermore the packages
themselves have inter-dependencies that must be correctly resolved.

So I'd need to ship my own FindZLIB, FindTIFF, FindPNG, FindJPEG, FindPROJ4,
FindHDF5, FindFFTW, ... etcetc, and override the ones of all my thirdparty
dependencies. It would create a maintenance hell :-(

How are other people resolving this?

All the best,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

Eric Noulard


2018-03-23 11:44 GMT+01:00 Mario Emmenlauer <[hidden email]>:

Hi Eric,

On 23.03.2018 10:58, Eric Noulard wrote:
> 2018-03-23 10:21 GMT+01:00 Mario Emmenlauer <[hidden email] <mailto:[hidden email]>>:
>
>
>     Thanks PF, I think this makes more sense now! I was assuming that
>     cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you
>     clarified, that only applies to libraries that provide find_package
>     support.
>
>     This is actually quite unfortunate. Then I don't see an easy way to
>     enforce usage of specific libs. As an example, if I want to enforce a
>     patched libtiff (that does not itself provide find_package support)
>     the only "safe" way is to replace the system libtiff. Otherwise any
>     package might just find the system version first without me even
>     knowing.
>
>
> You can always ship your own/patched version of  Find<Whatever>.cmake module with your
> project source and build the 'local' override logic in it for every project/lib that does not provide a find_package.
>
> Be sure to APPEND your local cmake module path (CMAKE_MODULE_PATH)
>
> something like:
>  list(APPEND CMAKE_MODULE_PATH ${AFS_SOURCE_DIR}/cmake)
>
> before using find_package etc...
>
> I find it a "safer" solution than system lib replacement.
> My opinion though.

I was considering this option too. But in my original email I outlined
that this is not only for my own package, but additionally for more than
30 thirdparty dependencies. So its not only about ensuring that my
packages use the correct thirdparty version, furthermore the packages
themselves have inter-dependencies that must be correctly resolved.

Sorry I missed that part on third party.

 
So I'd need to ship my own FindZLIB, FindTIFF, FindPNG, FindJPEG, FindPROJ4,
FindHDF5, FindFFTW, ... etcetc, and override the ones of all my thirdparty
dependencies. It would create a maintenance hell :-(

Yep I can perfectly imagine.
I know well a project for which we do exactly that.

1) Collect all third party sources for which we want to control precise version (and/or need a patch)
2) Configure, compile and install them all on a private dir
3) Configure and  build my project using those installed 3rd party libs. 
 
this is the only way we can find to have "clean" multi-linux-distrib' support.


How are other people resolving this?

I'm interesting in this as well, but as soon as a 3rd party is using something you use
you end-up putting your hand in third party or override system lib (which is not an option for us). 

--
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake