CMake find_package uses different search paths in different environments










0















I use CMake 3.10.2 for a C++ project and are experiencing a strange behavior of CMake when requiring a 3rd party library package and running CMake in different environments: I require a library (which I here call SOME_LIB) via



find_package(SOME_LIB REQUIRED)


and the search paths differ (the paths where CMake looks for packages) although the CMake call is the same in both enviroments. Both times CMake is called with some parameters, one being



-DSOME_LIB_DIR=/path/to/lib


providing the package's installation path.



In the first environment this works fine, but in the second system the library is not found:



CMake Warning at CMakeLists.txt:123 (find_package):
By not providing "FindSOME_LIB.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "SOME_LIB", but
CMake did not find one.

Could not find a package configuration file provided by "SOME_LIB" with any of
the following names:

SOME_LIBConfig.cmake
SOME_LIB-config.cmake

Add the installation prefix of "SOME_LIB" to CMAKE_PREFIX_PATH or set
"SOME_LIB_DIR" to a directory containing one of the above files. If "SOME_LIB"
provides a separate development package or SDK, be sure it has been
installed.


Adding the option



 -DCMAKE_FIND_DEBUG_MODE=ON


to the CMake call reveals that the search paths are different for the two environments. In particular only the first of the following documented search patterns is applied on the second system:



<prefix>/ (W)
<prefix>/(cmake|CMake)/ (W)
<prefix>/<name>*/ (W)
<prefix>/<name>*/(cmake|CMake)/ (W)
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U)
<prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (W/U)


Since the search pattern <prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ would be the one that finds the package in my situation, I thought initially that the second system is not recognized as a unix-like system, but the documentation also states, that "This is merely a convention, so all (W) and (U) directories are still searched on all platforms". So I should see all paths in CMake's debug output, shouldn't I?



The environments are:



  1. the first environment (works fine) is a Ubuntu 18.04 based docker container used for continuous integration with GitLab CI; the image is provisioned with some basic development tools and the 3rd party library I am using


  2. the second environment (package cannot be found; missing search paths) is a Ubuntu 18.04 windows subsystem for linux environment used for local development (freshly setup following the steps of the docker image)


Both environments have installed the same software packages including the cmake from the Ubuntu repositories (CMake 3.10.2). The library I want to use with find_package was built with CMake and installed in the same way in both environments. The directory contents of the library in the two environments are the same.



I also tried upgrading CMake in the second environment to 3.10.3 and 3.12.4 (both times built from sources), but the problem stays the same.










share|improve this question






















  • What happens if you compare a "CMake on plain Windows" environment with a "CMake on plain Ubuntu" environment? My guess is that CMake considers your first environment "Linux" and the second environment "Windows" where typical search paths and other conventions are "just different"

    – André
    Nov 15 '18 at 12:31












  • @André This is indeed something I could try. If you are right, then I misunderstood CMake's documentation (especially the sentence: "This is merely a convention, so all (W) and (U) directories are still searched on all platforms."), which led me to believe that all paths should be searched no matter whether it is Windows or Unix system.

    – Icarus
    Nov 15 '18 at 12:58






  • 1





    Could you be more specific with a path which is actually contains the "Config" file? You say about regex noted in documentation, but not all parts of regex are always searched (I mean arch part, which is searched only in specific cases). It is better to see exact path after the prefix. If you want to hide the library name, please, use X or x letters for show, whether a specific path component is lowercase ('xxx'), uppercase ('XXX') or camel case ('XxxXx').

    – Tsyvarev
    Nov 15 '18 at 13:26







  • 1





    Also, according to the documentation (and to my latest tests), the option XXX_DIR sets the exact directory, containing the required "XXXConfig.cmake" file. It is NOT a prefix, which is used in the path construction algorithm, described in the given documentation.

    – Tsyvarev
    Nov 15 '18 at 13:29
















0















I use CMake 3.10.2 for a C++ project and are experiencing a strange behavior of CMake when requiring a 3rd party library package and running CMake in different environments: I require a library (which I here call SOME_LIB) via



find_package(SOME_LIB REQUIRED)


and the search paths differ (the paths where CMake looks for packages) although the CMake call is the same in both enviroments. Both times CMake is called with some parameters, one being



-DSOME_LIB_DIR=/path/to/lib


providing the package's installation path.



In the first environment this works fine, but in the second system the library is not found:



CMake Warning at CMakeLists.txt:123 (find_package):
By not providing "FindSOME_LIB.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "SOME_LIB", but
CMake did not find one.

Could not find a package configuration file provided by "SOME_LIB" with any of
the following names:

SOME_LIBConfig.cmake
SOME_LIB-config.cmake

Add the installation prefix of "SOME_LIB" to CMAKE_PREFIX_PATH or set
"SOME_LIB_DIR" to a directory containing one of the above files. If "SOME_LIB"
provides a separate development package or SDK, be sure it has been
installed.


Adding the option



 -DCMAKE_FIND_DEBUG_MODE=ON


to the CMake call reveals that the search paths are different for the two environments. In particular only the first of the following documented search patterns is applied on the second system:



<prefix>/ (W)
<prefix>/(cmake|CMake)/ (W)
<prefix>/<name>*/ (W)
<prefix>/<name>*/(cmake|CMake)/ (W)
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U)
<prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (W/U)


Since the search pattern <prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ would be the one that finds the package in my situation, I thought initially that the second system is not recognized as a unix-like system, but the documentation also states, that "This is merely a convention, so all (W) and (U) directories are still searched on all platforms". So I should see all paths in CMake's debug output, shouldn't I?



The environments are:



  1. the first environment (works fine) is a Ubuntu 18.04 based docker container used for continuous integration with GitLab CI; the image is provisioned with some basic development tools and the 3rd party library I am using


  2. the second environment (package cannot be found; missing search paths) is a Ubuntu 18.04 windows subsystem for linux environment used for local development (freshly setup following the steps of the docker image)


Both environments have installed the same software packages including the cmake from the Ubuntu repositories (CMake 3.10.2). The library I want to use with find_package was built with CMake and installed in the same way in both environments. The directory contents of the library in the two environments are the same.



I also tried upgrading CMake in the second environment to 3.10.3 and 3.12.4 (both times built from sources), but the problem stays the same.










share|improve this question






















  • What happens if you compare a "CMake on plain Windows" environment with a "CMake on plain Ubuntu" environment? My guess is that CMake considers your first environment "Linux" and the second environment "Windows" where typical search paths and other conventions are "just different"

    – André
    Nov 15 '18 at 12:31












  • @André This is indeed something I could try. If you are right, then I misunderstood CMake's documentation (especially the sentence: "This is merely a convention, so all (W) and (U) directories are still searched on all platforms."), which led me to believe that all paths should be searched no matter whether it is Windows or Unix system.

    – Icarus
    Nov 15 '18 at 12:58






  • 1





    Could you be more specific with a path which is actually contains the "Config" file? You say about regex noted in documentation, but not all parts of regex are always searched (I mean arch part, which is searched only in specific cases). It is better to see exact path after the prefix. If you want to hide the library name, please, use X or x letters for show, whether a specific path component is lowercase ('xxx'), uppercase ('XXX') or camel case ('XxxXx').

    – Tsyvarev
    Nov 15 '18 at 13:26







  • 1





    Also, according to the documentation (and to my latest tests), the option XXX_DIR sets the exact directory, containing the required "XXXConfig.cmake" file. It is NOT a prefix, which is used in the path construction algorithm, described in the given documentation.

    – Tsyvarev
    Nov 15 '18 at 13:29














0












0








0








I use CMake 3.10.2 for a C++ project and are experiencing a strange behavior of CMake when requiring a 3rd party library package and running CMake in different environments: I require a library (which I here call SOME_LIB) via



find_package(SOME_LIB REQUIRED)


and the search paths differ (the paths where CMake looks for packages) although the CMake call is the same in both enviroments. Both times CMake is called with some parameters, one being



-DSOME_LIB_DIR=/path/to/lib


providing the package's installation path.



In the first environment this works fine, but in the second system the library is not found:



CMake Warning at CMakeLists.txt:123 (find_package):
By not providing "FindSOME_LIB.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "SOME_LIB", but
CMake did not find one.

Could not find a package configuration file provided by "SOME_LIB" with any of
the following names:

SOME_LIBConfig.cmake
SOME_LIB-config.cmake

Add the installation prefix of "SOME_LIB" to CMAKE_PREFIX_PATH or set
"SOME_LIB_DIR" to a directory containing one of the above files. If "SOME_LIB"
provides a separate development package or SDK, be sure it has been
installed.


Adding the option



 -DCMAKE_FIND_DEBUG_MODE=ON


to the CMake call reveals that the search paths are different for the two environments. In particular only the first of the following documented search patterns is applied on the second system:



<prefix>/ (W)
<prefix>/(cmake|CMake)/ (W)
<prefix>/<name>*/ (W)
<prefix>/<name>*/(cmake|CMake)/ (W)
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U)
<prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (W/U)


Since the search pattern <prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ would be the one that finds the package in my situation, I thought initially that the second system is not recognized as a unix-like system, but the documentation also states, that "This is merely a convention, so all (W) and (U) directories are still searched on all platforms". So I should see all paths in CMake's debug output, shouldn't I?



The environments are:



  1. the first environment (works fine) is a Ubuntu 18.04 based docker container used for continuous integration with GitLab CI; the image is provisioned with some basic development tools and the 3rd party library I am using


  2. the second environment (package cannot be found; missing search paths) is a Ubuntu 18.04 windows subsystem for linux environment used for local development (freshly setup following the steps of the docker image)


Both environments have installed the same software packages including the cmake from the Ubuntu repositories (CMake 3.10.2). The library I want to use with find_package was built with CMake and installed in the same way in both environments. The directory contents of the library in the two environments are the same.



I also tried upgrading CMake in the second environment to 3.10.3 and 3.12.4 (both times built from sources), but the problem stays the same.










share|improve this question














I use CMake 3.10.2 for a C++ project and are experiencing a strange behavior of CMake when requiring a 3rd party library package and running CMake in different environments: I require a library (which I here call SOME_LIB) via



find_package(SOME_LIB REQUIRED)


and the search paths differ (the paths where CMake looks for packages) although the CMake call is the same in both enviroments. Both times CMake is called with some parameters, one being



-DSOME_LIB_DIR=/path/to/lib


providing the package's installation path.



In the first environment this works fine, but in the second system the library is not found:



CMake Warning at CMakeLists.txt:123 (find_package):
By not providing "FindSOME_LIB.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "SOME_LIB", but
CMake did not find one.

Could not find a package configuration file provided by "SOME_LIB" with any of
the following names:

SOME_LIBConfig.cmake
SOME_LIB-config.cmake

Add the installation prefix of "SOME_LIB" to CMAKE_PREFIX_PATH or set
"SOME_LIB_DIR" to a directory containing one of the above files. If "SOME_LIB"
provides a separate development package or SDK, be sure it has been
installed.


Adding the option



 -DCMAKE_FIND_DEBUG_MODE=ON


to the CMake call reveals that the search paths are different for the two environments. In particular only the first of the following documented search patterns is applied on the second system:



<prefix>/ (W)
<prefix>/(cmake|CMake)/ (W)
<prefix>/<name>*/ (W)
<prefix>/<name>*/(cmake|CMake)/ (W)
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U)
<prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (W/U)


Since the search pattern <prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ would be the one that finds the package in my situation, I thought initially that the second system is not recognized as a unix-like system, but the documentation also states, that "This is merely a convention, so all (W) and (U) directories are still searched on all platforms". So I should see all paths in CMake's debug output, shouldn't I?



The environments are:



  1. the first environment (works fine) is a Ubuntu 18.04 based docker container used for continuous integration with GitLab CI; the image is provisioned with some basic development tools and the 3rd party library I am using


  2. the second environment (package cannot be found; missing search paths) is a Ubuntu 18.04 windows subsystem for linux environment used for local development (freshly setup following the steps of the docker image)


Both environments have installed the same software packages including the cmake from the Ubuntu repositories (CMake 3.10.2). The library I want to use with find_package was built with CMake and installed in the same way in both environments. The directory contents of the library in the two environments are the same.



I also tried upgrading CMake in the second environment to 3.10.3 and 3.12.4 (both times built from sources), but the problem stays the same.







c++ cmake






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 15 '18 at 12:13









IcarusIcarus

6131612




6131612












  • What happens if you compare a "CMake on plain Windows" environment with a "CMake on plain Ubuntu" environment? My guess is that CMake considers your first environment "Linux" and the second environment "Windows" where typical search paths and other conventions are "just different"

    – André
    Nov 15 '18 at 12:31












  • @André This is indeed something I could try. If you are right, then I misunderstood CMake's documentation (especially the sentence: "This is merely a convention, so all (W) and (U) directories are still searched on all platforms."), which led me to believe that all paths should be searched no matter whether it is Windows or Unix system.

    – Icarus
    Nov 15 '18 at 12:58






  • 1





    Could you be more specific with a path which is actually contains the "Config" file? You say about regex noted in documentation, but not all parts of regex are always searched (I mean arch part, which is searched only in specific cases). It is better to see exact path after the prefix. If you want to hide the library name, please, use X or x letters for show, whether a specific path component is lowercase ('xxx'), uppercase ('XXX') or camel case ('XxxXx').

    – Tsyvarev
    Nov 15 '18 at 13:26







  • 1





    Also, according to the documentation (and to my latest tests), the option XXX_DIR sets the exact directory, containing the required "XXXConfig.cmake" file. It is NOT a prefix, which is used in the path construction algorithm, described in the given documentation.

    – Tsyvarev
    Nov 15 '18 at 13:29


















  • What happens if you compare a "CMake on plain Windows" environment with a "CMake on plain Ubuntu" environment? My guess is that CMake considers your first environment "Linux" and the second environment "Windows" where typical search paths and other conventions are "just different"

    – André
    Nov 15 '18 at 12:31












  • @André This is indeed something I could try. If you are right, then I misunderstood CMake's documentation (especially the sentence: "This is merely a convention, so all (W) and (U) directories are still searched on all platforms."), which led me to believe that all paths should be searched no matter whether it is Windows or Unix system.

    – Icarus
    Nov 15 '18 at 12:58






  • 1





    Could you be more specific with a path which is actually contains the "Config" file? You say about regex noted in documentation, but not all parts of regex are always searched (I mean arch part, which is searched only in specific cases). It is better to see exact path after the prefix. If you want to hide the library name, please, use X or x letters for show, whether a specific path component is lowercase ('xxx'), uppercase ('XXX') or camel case ('XxxXx').

    – Tsyvarev
    Nov 15 '18 at 13:26







  • 1





    Also, according to the documentation (and to my latest tests), the option XXX_DIR sets the exact directory, containing the required "XXXConfig.cmake" file. It is NOT a prefix, which is used in the path construction algorithm, described in the given documentation.

    – Tsyvarev
    Nov 15 '18 at 13:29

















What happens if you compare a "CMake on plain Windows" environment with a "CMake on plain Ubuntu" environment? My guess is that CMake considers your first environment "Linux" and the second environment "Windows" where typical search paths and other conventions are "just different"

– André
Nov 15 '18 at 12:31






What happens if you compare a "CMake on plain Windows" environment with a "CMake on plain Ubuntu" environment? My guess is that CMake considers your first environment "Linux" and the second environment "Windows" where typical search paths and other conventions are "just different"

– André
Nov 15 '18 at 12:31














@André This is indeed something I could try. If you are right, then I misunderstood CMake's documentation (especially the sentence: "This is merely a convention, so all (W) and (U) directories are still searched on all platforms."), which led me to believe that all paths should be searched no matter whether it is Windows or Unix system.

– Icarus
Nov 15 '18 at 12:58





@André This is indeed something I could try. If you are right, then I misunderstood CMake's documentation (especially the sentence: "This is merely a convention, so all (W) and (U) directories are still searched on all platforms."), which led me to believe that all paths should be searched no matter whether it is Windows or Unix system.

– Icarus
Nov 15 '18 at 12:58




1




1





Could you be more specific with a path which is actually contains the "Config" file? You say about regex noted in documentation, but not all parts of regex are always searched (I mean arch part, which is searched only in specific cases). It is better to see exact path after the prefix. If you want to hide the library name, please, use X or x letters for show, whether a specific path component is lowercase ('xxx'), uppercase ('XXX') or camel case ('XxxXx').

– Tsyvarev
Nov 15 '18 at 13:26






Could you be more specific with a path which is actually contains the "Config" file? You say about regex noted in documentation, but not all parts of regex are always searched (I mean arch part, which is searched only in specific cases). It is better to see exact path after the prefix. If you want to hide the library name, please, use X or x letters for show, whether a specific path component is lowercase ('xxx'), uppercase ('XXX') or camel case ('XxxXx').

– Tsyvarev
Nov 15 '18 at 13:26





1




1





Also, according to the documentation (and to my latest tests), the option XXX_DIR sets the exact directory, containing the required "XXXConfig.cmake" file. It is NOT a prefix, which is used in the path construction algorithm, described in the given documentation.

– Tsyvarev
Nov 15 '18 at 13:29






Also, according to the documentation (and to my latest tests), the option XXX_DIR sets the exact directory, containing the required "XXXConfig.cmake" file. It is NOT a prefix, which is used in the path construction algorithm, described in the given documentation.

– Tsyvarev
Nov 15 '18 at 13:29













1 Answer
1






active

oldest

votes


















0














The comment by Tsyvarev led me to the answer of my problem:



The problem was caused by my missunderstanding of the



-D<PACKAGE>_DIR=/path/to/config


parameter. As Tsyvarev pointed out the documentation says that <PACKAGE>_DIR must point to the exact path to the directory contatining the config files <PACKAGE>-config.cmake. In other words it is not a prefix path.



It remains the question why it worked in one of the two enviroments: the reason is that I had a small but important variation between the library's installation paths in both environments that I did not notice before:



  1. First environment (docker container): /opt/<library_name>-<version-number>/ (note the - which is important!)

  2. Second environment (Windows Subsystem for Linux Ubuntu): /opt/<library_name>/<version-number>/

Note: both paths contained the same contents with the CMake configuration being in




  1. /opt/<library_name>-<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the first environment and, respectively, in


  2. /opt/<library_name>/<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the second environment.

In the first environment the library was found since the pattern <prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ matched, where /opt is one of CMake's <prefix> paths and the <name>* was expanded to <library_name>-<version-number> - an expansion which was not possible for the path in the second environment.



Many thanks for the helpful comments. My apologies for missing the path variation (have looked at the problem for two days but did not see that).






share|improve this answer






















    Your Answer






    StackExchange.ifUsing("editor", function ()
    StackExchange.using("externalEditor", function ()
    StackExchange.using("snippets", function ()
    StackExchange.snippets.init();
    );
    );
    , "code-snippets");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "1"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53319272%2fcmake-find-package-uses-different-search-paths-in-different-environments%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    The comment by Tsyvarev led me to the answer of my problem:



    The problem was caused by my missunderstanding of the



    -D<PACKAGE>_DIR=/path/to/config


    parameter. As Tsyvarev pointed out the documentation says that <PACKAGE>_DIR must point to the exact path to the directory contatining the config files <PACKAGE>-config.cmake. In other words it is not a prefix path.



    It remains the question why it worked in one of the two enviroments: the reason is that I had a small but important variation between the library's installation paths in both environments that I did not notice before:



    1. First environment (docker container): /opt/<library_name>-<version-number>/ (note the - which is important!)

    2. Second environment (Windows Subsystem for Linux Ubuntu): /opt/<library_name>/<version-number>/

    Note: both paths contained the same contents with the CMake configuration being in




    1. /opt/<library_name>-<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the first environment and, respectively, in


    2. /opt/<library_name>/<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the second environment.

    In the first environment the library was found since the pattern <prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ matched, where /opt is one of CMake's <prefix> paths and the <name>* was expanded to <library_name>-<version-number> - an expansion which was not possible for the path in the second environment.



    Many thanks for the helpful comments. My apologies for missing the path variation (have looked at the problem for two days but did not see that).






    share|improve this answer



























      0














      The comment by Tsyvarev led me to the answer of my problem:



      The problem was caused by my missunderstanding of the



      -D<PACKAGE>_DIR=/path/to/config


      parameter. As Tsyvarev pointed out the documentation says that <PACKAGE>_DIR must point to the exact path to the directory contatining the config files <PACKAGE>-config.cmake. In other words it is not a prefix path.



      It remains the question why it worked in one of the two enviroments: the reason is that I had a small but important variation between the library's installation paths in both environments that I did not notice before:



      1. First environment (docker container): /opt/<library_name>-<version-number>/ (note the - which is important!)

      2. Second environment (Windows Subsystem for Linux Ubuntu): /opt/<library_name>/<version-number>/

      Note: both paths contained the same contents with the CMake configuration being in




      1. /opt/<library_name>-<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the first environment and, respectively, in


      2. /opt/<library_name>/<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the second environment.

      In the first environment the library was found since the pattern <prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ matched, where /opt is one of CMake's <prefix> paths and the <name>* was expanded to <library_name>-<version-number> - an expansion which was not possible for the path in the second environment.



      Many thanks for the helpful comments. My apologies for missing the path variation (have looked at the problem for two days but did not see that).






      share|improve this answer

























        0












        0








        0







        The comment by Tsyvarev led me to the answer of my problem:



        The problem was caused by my missunderstanding of the



        -D<PACKAGE>_DIR=/path/to/config


        parameter. As Tsyvarev pointed out the documentation says that <PACKAGE>_DIR must point to the exact path to the directory contatining the config files <PACKAGE>-config.cmake. In other words it is not a prefix path.



        It remains the question why it worked in one of the two enviroments: the reason is that I had a small but important variation between the library's installation paths in both environments that I did not notice before:



        1. First environment (docker container): /opt/<library_name>-<version-number>/ (note the - which is important!)

        2. Second environment (Windows Subsystem for Linux Ubuntu): /opt/<library_name>/<version-number>/

        Note: both paths contained the same contents with the CMake configuration being in




        1. /opt/<library_name>-<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the first environment and, respectively, in


        2. /opt/<library_name>/<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the second environment.

        In the first environment the library was found since the pattern <prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ matched, where /opt is one of CMake's <prefix> paths and the <name>* was expanded to <library_name>-<version-number> - an expansion which was not possible for the path in the second environment.



        Many thanks for the helpful comments. My apologies for missing the path variation (have looked at the problem for two days but did not see that).






        share|improve this answer













        The comment by Tsyvarev led me to the answer of my problem:



        The problem was caused by my missunderstanding of the



        -D<PACKAGE>_DIR=/path/to/config


        parameter. As Tsyvarev pointed out the documentation says that <PACKAGE>_DIR must point to the exact path to the directory contatining the config files <PACKAGE>-config.cmake. In other words it is not a prefix path.



        It remains the question why it worked in one of the two enviroments: the reason is that I had a small but important variation between the library's installation paths in both environments that I did not notice before:



        1. First environment (docker container): /opt/<library_name>-<version-number>/ (note the - which is important!)

        2. Second environment (Windows Subsystem for Linux Ubuntu): /opt/<library_name>/<version-number>/

        Note: both paths contained the same contents with the CMake configuration being in




        1. /opt/<library_name>-<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the first environment and, respectively, in


        2. /opt/<library_name>/<version-number>/lib/cmake/<library_name>/<library_name>-config.cmake for the second environment.

        In the first environment the library was found since the pattern <prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ matched, where /opt is one of CMake's <prefix> paths and the <name>* was expanded to <library_name>-<version-number> - an expansion which was not possible for the path in the second environment.



        Many thanks for the helpful comments. My apologies for missing the path variation (have looked at the problem for two days but did not see that).







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 15 '18 at 16:18









        IcarusIcarus

        6131612




        6131612





























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53319272%2fcmake-find-package-uses-different-search-paths-in-different-environments%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            這個網誌中的熱門文章

            How to read a connectionString WITH PROVIDER in .NET Core?

            Node.js Script on GitHub Pages or Amazon S3

            Museum of Modern and Contemporary Art of Trento and Rovereto