[CMake] Evaluate generator expressions with install interface

[P F via CMake]

Hi,

I would like to evaluate generator expressions to generate a pkgconfig file. 
Something like:

function(auto_pkgconfig TARGET)
file(GENERATE OUTPUT ${TARGET}.pc CONTENT "
Name: ${TARGET}
Cflags: -I$, -I>
Libs: -L$ -l${TARGET}
")
install(FILES ${TARGET}.pc DESTINATION lib/pkgconfig)
endfunction()

However, this doesn’t work very well. It always evaluates the build interface 
or computes the TARGET_FILE_DIR according the build directory instead of 
installation. Also, if include directories are added to the target after 
calling `auto_pkgconfig` it doesn’t capture those(ie it runs file(GENERATE) at 
config time instead of generator time).

So, is there a way to evaluate generator expressions for installation? And 
evaluate them at generator time? 

Calling `file(GENERATE)` at installation time(with install(CODE) or 
install(SCRIPT)) does not solve this problem either.

Thanks,
Paul
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] [Config-file Package] The best practice of finding package dependencies?

[P F via CMake]

> On Jun 20, 2017, at 10:46 PM, Konstantin Podsvirov  
> wrote:
> 
> Hello community!
> 
> I want to give a little discussion :)
> 
> If I export a package containing several targets.
> And these target are publicly linked to the targets imported from another 
> package.
> Where is the best place to look for package dependencies?
> 
> I assume the following options:
> - In the Config-file of the package itself;

I believe this is the best practice, and it is why the `find_dependency` macro 
exists. 

> - The user himself must find them in his project.
> 
> It seems to me that to force the user to look for the dependencies of the 
> package, which he himself seeks there is bad tone, but also to impose on the 
> user, then how I myself found these dependencies in Config-file may not 
> appeal to everyone.
> 
> Perhaps there should be some option for setting the behavior of the 
> `find_package` command in the part of finding package dependencies? Or she 
> already is, but I have not yet studied it.

The user can either use `_DIR` to tell cmake exactly where the package 
is, or they can call `find_package(…)` beforehand. However, if the user wants 
something completely different then they would either need to provide a Find 
module or override `find_package`. 

For example, this is common for projects that build their dependencies in the 
same project:

set(as_subproject Foo)
macro(find_package)
  if(NOT "${ARG0}" IN_LIST as_subproject)
_find_package(${ARGV})
  endif()
endmacro()
add_subdirectory(Foo)
add_subdirectory(App)

This makes `find_package(Foo)` do nothing since the target `Foo::Foo` would be 
part of the project.


-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] find_package(), FindXXX.cmake and IMPORTED add_library()

[P F via CMake]

> On Jun 30, 2017, at 6:40 AM, Louis-Paul CORDIER  
> wrote:
> 
> Hi,
> 
> I'm particularly familiar with find_package() command, add_library(... 
> IMPORTED) and find_library(). However, I found there are many differences on 
> find_package() usage depending of the library being imported.
> 
> For instance, using find_package() on Qt5 will retrieve a bunch of 
> *Config.cmake files in the Qt installation tree, and add each components as a 
> library using add_library(Qt5::COMPONENT SHARED IMPORTED).
> One nice feature with that is the possibility to retrieve the LOCATION 
> property on each component to get the DLL file.
> 
> That said when using find_package(sharedLibFOO) that will make use of 
> hand-written FindsharedLibFOO.cmake, some variables like FindsharedLib_FOUND, 
> FindsharedLib_LIBRARIES, FindsharedLib_VERSION (etc.) are set by the script, 
> but there is almost never add_library() command used inside this CMake find 
> script.
> 
> 1. Should it be mandatory to use add_library() in FindXXX.cmake scripts, so 
> the user just needs to target_link_libraries() and all compile definitions, 
> includes dir, and lib dir are automatically imported?

This probably should be the case, but I think a lack of contributions is the 
problem with the current Find modules not being update on each module.

> 2. If not, is it a good practice to use add_library() when writing our 
> FindXXX.cmake package?

When writing your own FindXXX.cmake, you should first report a bug to library 
XXX for not supporting cmake downstream. Also, the purpose of `find_package` is 
to find prebuilt binaries, its not to add new libraries to be built.

> 3. When making an application, is it a good practice to create an imported 
> target for each library, instead of appending manually to the current project 
> using target_link_libraries(), target_compile_definitions(), 
> target_include_directories() and so on?

Yes, it is good practice to make your dependencies imported targets as it 
allows for the dependencies to be relocatable.

Here is some more information about cmake packages:

https://cmake.org/cmake/help/v3.7/manual/cmake-packages.7.html


-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Interest in adding to CMake the CMakeGet module to get dependencies

[P F via CMake]

> On Aug 4, 2017, at 9:18 PM, Craig Scott  wrote:
> 
> TLDR: There may be other work already covering similar capabilities (e.g. 
> hunter and WIP that I'm uncloaking here). This response is mostly about 
> providing broader discussion.
> 
> 
> Paul it seems you've been busy since you first asked about cget 
>  on this list last 
> year. ;)

Thanks, cget has improved a lot in the last year.

> 
> In the interests of disclosure, this latest email of yours has prompted me to 
> uncloak some of my own work which may be relevant. This work has been in 
> development and testing on real world projects for the past 2 years or so. 
> Without wanting to hijack your thread, let me give a little info about it and 
> then see my responses to your comments at the end for how/why I think this 
> may be relevant to your request for comments.
> 
> ExternalProject can be used in a different way to allow it to perform 
> downloads at configure time rather than build time. You can see a relatively 
> straightforward implementation of this here:
> 
> https://github.com/Crascit/DownloadProject 
> 
> 

That seems to support the `add_subdirectory` workflow, but how would it work 
when using the `find_package` workflow? This workflow is useful to help package 
manager tools(including those which pulls binaries).

> This has the advantage of leveraging all of the various download methods 
> ExternalProject already provides, meaning they are already fairly widely used 
> and tested. Any improvements to ExternalProject also come for free and 
> documentation for the various methods is also provided (I recently overhauled 
> the ExternalProject docs and these will appear in the 3.10.0 release, but 
> they can be viewed in the master docs 
>  in the 
> meantime). ExternalProject also has the advantage that it supports updating 
> after the initial download in the case of repository sources like git, svn, 
> etc.
> 
> The uncloaking part of my response is that I have been working on a full 
> dependency download framework over the past year and half which is built on 
> top of the above DownloadProject implementation. It supports hierarchical 
> dependencies across complex project structures and makes it very easy for 
> projects to pull in other projects, including support for higher level 
> projects being able to override dependency details of projects lower in the 
> dependency tree if they want to. I've been incubating this privately in a 
> real world company environment to iron out the kinks and ensure the interface 
> that projects interact with supports the right set of features and that less 
> knowledgable users can understand it, etc. I'm planning on putting both 
> DownloadProject and the dependency framework up for review to merge into 
> CMake within the next few months, all going well. Whereas your work seems to 
> focus on building and/or re-using an installed/binary result, my work focuses 
> more on making external projects part of your main build. This has advantages 
> like using the same compiler settings, toolchain details, etc. and all of the 
> dependency targets are automatically available to the rest of the project if 
> the dependency uses CMake as its build system. I'll postpone further details 
> on it until it is ready for review, but that should be enough for context for 
> my responses to your comments further below.
> 
> There's also hunter , which you've already 
> been made aware of and which is closer to your proposal in terms of the set 
> of problems it tries to solve. Hunter has been around for a while, is 
> reasonably well known and on the face of it, already seems to do all the 
> things cmake-get is trying to do. It is also based on ExternalProject. It may 
> be helpful if you could show how your work differs from what hunter already 
> provides so that its value to the CMake community is clear.
> 
> Hopefully that's not too overwhelming for background/context. See my 
> responses in the remainder below.
> 
> 
> 
> On Sat, Aug 5, 2017 at 5:57 AM, paul via CMake  > wrote:
> Hi,
> 
> I have a written a cmake module to get dependencies using the cget protocol
> here:
> 
> https://github.com/pfultz2/cmake-get 
> 
> This is different than `ExternelProject`:
> 
> * `ExternelProject` happens only during build, which allows this module to
> work in both in config and script mode. 
> 
> As detailed above, you can use ExternalProject at configure time too and 
> there's already a relatively simple, generic implementation available showing 
> how to do it for the download case.
> 
>  
> * In config mode, the user can just do:
> 
> cmake_get( PREFIX ${CMAKE_CURRENT_BINARY_DIR}/deps)
> find_package( HINTS ${CMAKE_CURRENT_BINARY_DIR}/deps)

Re: [CMake] Should configuration package files define module package variables?

[P F via CMake]

> On Aug 25, 2017, at 11:21 AM, Robert Dailey  wrote:
> 
> So I've been studying the find_package[1] and "creating packages"[2]
> documentation, as well as the CMakePackageConfigHelpers[3] page.
> 
> Based on the current offerings of configuration packages, I do not
> understand the need for the relocatable config.cmake file when all it
> really contains is:
> 
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)

In general, if the library does not have any dependencies, you can just export 
the targets directly to the config.cmake file:

install(TARGETS foo EXPORT foo-config)
install(EXPORT foo-config DESTINATION lib/cmake/foo)

However, if the library has dependencies, you will need to iterate over them in 
the config.cmake file. That is if `foo` uses zlib, like this:

find_package(ZLIB)
target_link_libraries(foo ZLIB::ZLIB)

Then the foo-config.cmake needs to do this(assuming the export targets are 
written to foo-targets):

include(CMakeFindDependencyMacro)
find_dependency(ZLIB)
include("${CMAKE_CURRENT_LIST_DIR}/foo-targets.cmake”)

The reason for this is that the imported foo target will link against 
ZLIB::ZLIB, but it will not define it. Actually, the generated 
foo-targets.cmake will create an error if ZLIB::ZLIB doesn’t exists, which is 
why `find_dependency(ZLIB)`(which is really just `find_package` underneath) 
needs to be called before including the foo-targets.cmake.

Hopefully that makes sense.

> 
> However, what I'm wondering is even though the import targets should
> contain all information about include directories, libraries, etc,
> should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
> variables? Example of what foo-config.cmake would be like:
> 
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
> set( Foo_INCLUDE_DIRS "... path here" )
> set( Foo_LIBRARIES "List of libraries here...” )

In general, defining relocatable variables like `Foo_INCLUDE_DIRS` was more 
common in with cmake 2.8. With modern cmake using just the imported targets is 
much better then dealing with all those variables and trying to make them 
relocatable.


-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Adding compile and build type tests to CMake/CTest

[P F via CMake]

The `add_test` function can run whatever command you want it to, including 
compiling a target:

add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp)
add_test(NAME foo_compile_test
COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config 
$
WORKING_DIRECTORY ${CMAKE_BINARY_DIR})

Then you set cmake to expect failure:

set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE)

You can also check for output instead of just expecting failure:

set_tests_properties(mytest PROPERTIES
  PASS_REGULAR_EXPRESSION "foo failed"
)

This is especially useful to make sure that the error is from the static_assert 
message and not from another compile error.

Of course, cmake could provide a module which provides a function to do this, 
which additionally could help workaround the caveats of this approach. This is 
essentially what `bcm_test` in the boost cmake modules do. Hopefully, in the 
future this module could be merged upstream into cmake.


> On Sep 5, 2017, at 11:44 AM, Edward Diener  
> wrote:
> 
> On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote:
>> There's already CheckCXXSourceCompiles and friends.
>> The only problem is that try_compile is not scriptable otherwise you could 
>> let the test invoke
>> ${CMAKE_COMMAND} -P check_source_compiles.cmake.
> 
> To put it succinctly CMake should adding compile-time testing so that when 
> some compilation succeeds the test is successful and if the compilation fails 
> the test is not successful, with the proviso that you can reverse the result 
> as a compile should fail type of test. Similarly a build type testing, 
> without having to run anything should be added along the same lines.
> 
> In modern C++ it is perfectly feasible, especially with template programming, 
> to do compile time testing, invoking a compile-time static assert as a 
> compile-time failure. Boost has had this for years and modern C++ has it as 
> part of the latest version of the C++ standard. CMake needs to update itself 
> to the reality that pure compile-time testing is a reality for modern C++ and 
> should update itself accordingly. Only having run-time testing is an artifact 
> of the past. Hopefully CMake developers will get the message and make the 
> necessary update to CMake/CTest.
> 
>> -Original Message-
>> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Roger Leigh
>> Sent: Monday, September 4, 2017 16:51
>> To: cmake@cmake.org
>> Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest
>> On 04/09/17 14:40, Edward Diener wrote:
>>> Boost Build has tests for running an application successfully or not,
>>> for compiling one or more source files successfully or not, and for
>>> building one or more source files into an exe or not. These tests in
>>> Boost Build are the run/run-fail, compile/compile-fail, and
>>> link/link-fail rules.
>>> 
>>> CMake/CTest has the exact equivalent to the run/run-fail rule in its
>>> add_test framework, but there is not add_test equivalent to the other
>>> two sets of rules. It sure would be nice, when Boost transitions to
>>> using CMake/CTest instead of Boost Build, if CMake/CTest had the
>>> equivalent of the other two sets of types of test in its add_test
>>> framework.
>>> 
>>> Is there any consensus that these other two types of tests might be
>>> valuable for CMake/CTest, or any way to make this happen ?
>> I've certainly wished for them.  Particularly when testing templated code 
>> where you want to test that certain things fail correctly, e.g. via 
>> static_assert or simply being invalid.
>> I understand it's possible to make this work partially, by creating targets 
>> which aren't built by default, and then add tests which invoke the targets.  
>> But this appears to have some caveats, such as potential misbehaviour with 
>> parallel testing.  Or you can have a separate CMake build for each 
>> individual target, but it's extra complexity.  Having a proper means of 
>> registering such tests would be very, very nice.
>> Regards,
>> Roger
> 
> 
> -- 
> 
> 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:
> http://public.kitware.com/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.or

Re: [CMake] Proper process for static & shared variants of config packages?

[P F via CMake]

> On Sep 1, 2017, at 10:39 AM, Robert Dailey  wrote:
> 
> Suppose I have a library target and I setup a config package for it
> and install target exports for it. What is the process for supporting
> installation of the shared library and static library variants (maybe
> the same answer applies to debug and release variants too)?
> 
> Should you create 1 target and rely on BUILD_SHARED_LIBS, which means
> generating two binary directories, building and installing once in
> each?

This is the best approach as it leaves the decision of building shared or 
static to the clients.

> Will this overwrite existing target.cmake and config.cmake files
> in a negative way?

You could install each variant of shared and static to separate install 
directories. For debug and release you can install together, as cmake generates 
a target-.cmake for each configuration. I suppose you could 
embed some logic in the config.cmake file to pick a different export file for 
shared or static as well.

> 
> Or should there be 2 library targets (something like foo_shared and
> foo_static) and build & install once?

No, this is rather problematic:

1) If your dependencies are built for just one variant as well, then one of 
those targets could fail.

2) A downstream library may only want to create 1 target, and now it has to add 
extra logic to decide if it should choose the shared or static target, which is 
cumbersome.


-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Change compiler for certain files in the project

[P F via CMake]

> On Oct 28, 2017, at 9:50 AM, Aaron Boxer  wrote:
> 
> Hello,
> 
> I have a cmake project on linux, and I would like to change the compiler
> for certain files from g++ to  another, llvm-based compiler called hcc.
> (hcc is AMDs HIP compiler for GPGPU)
> 
> 
> Is there a way of doing this in my cmake file ?

There isn’t a simple way to do that. The FindCUDA and FindHIP cmake modules do 
that, but its not at all easy to follow, and brings its own set of issues.

Of course, why do you need to use g++ to compile host code? Being clang-based 
hcc should be able to compile any g++ code. So you can just use hcc as the 
compiler for everything and then link with the `hccrt` cmake target(provided by 
`find_package(hcc)`) which will enable GPU compiling when you want to compile 
code for the device.


-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] cmake sometimes don't find the header

[P F via CMake]

I am not sure, but you should write the cmake target-oriented(instead of using 
variables). So you shouldn’t use `include_directories` either. It should be 
written:

#
# Build static library
add_library(database database.cpp database.h)

target_compile_features(database PUBLIC cxx_defaulted_functions)
target_include_directories(database PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
target_link_libraries(database record spectogram)

And record and spectogram should be written in a similar fashion. By using 
targets, you don’t have to worry about the targets being defined yet, so the 
superproject doesn’t need to order the `add_subdirectory` calls(it can even 
support circular dependencies).

Another thing, you shouldn’t declare another project unless you planning on 
making it standalone. This means it should find the dependencies through 
`find_package` and be installable with its usage requirements, which would be 
written like this:

project(database)

find_package(record)
find_package(spectogram)

#
# Build static library
add_library(database database.cpp database.h)

target_compile_features(database PUBLIC cxx_defaulted_functions)
target_include_directories(database PUBLIC 
$)
target_link_libraries(database record spectogram)

install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/database.h DESTINATION include)

install(TARGETS database EXPORT database-targets
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib
INCLUDES DESTINATION include
)

install(EXPORT database-targets
FILE database-targets.cmake
DESTINATION lib/cmake/database
)

file(WRITE "${PROJECT_BINARY_DIR}/database-config.cmake" "
include(CMakeFindDependencyMacro)
find_dependency(record)
find_dependency(spectogram)
include(\"\${CMAKE_CURRENT_LIST_DIR}/database-targets.cmake\")
")

write_basic_package_version_file("${PROJECT_BINARY_DIR}/database-config-version.cmake"
VERSION 1.0
COMPATIBILITY AnyNewerVersion
)

install(FILES
"${PROJECT_BINARY_DIR}/database-config.cmake"
"${PROJECT_BINARY_DIR}/database-config-version.cmake"
DESTINATION lib/cmake/database
)

The dependencies can be found either through find_package for standalone or 
through add_subdirectory in the superproject by overriding find_package. The 
effective cmake talk describes how such setup works, here:

https://www.youtube.com/watch?v=bsXLMQ6WgIk 


Or you can use a single project for all components.

> On Nov 12, 2017, at 8:04 AM, Carlton Banks  wrote:
> 
> I am not sure I understand why I am having this problem..
> but cmake seem to have some problems with finding the header file located in 
> a different project. 
> 
> tree view of my system: https://pastebin.com/AvydEbeW
> 
> I’ve included the directory to the project which header files I am interested 
> in, and also added the path in my 
> target_inlcude_directories. The problems is my database.h cannot see record.h.
> 
> database/CmakeLists.txt:
> 
> https://pastebin.com/DpcMjtMa
> 
> The weird part is that it sometimes is able to compile, and other times it 
> get stuck with this not able to find the header?
> 
> what could the problem be?
> 
> 
> 
> 
> -- 
> 
> 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:
> http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

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

[P F via CMake]

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  > 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 
> 

Re: [CMake] find_package() for static only / shared only

[P F via CMake]

Why not install shared libraries in one location and static libraries in 
another?

> On Mar 21, 2018, at 4:55 AM, Mario Emmenlauer  wrote:
> 
> 
> I've googled this issue for a while now but found only few
> references (1,2) and no solution. I'd like to enforce that
> find_package() will only accept static or shared libraries.
> I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF).
> 
> I.e. I'd love to have something like:
>if(BUILD_SHARED_LIBS)
>BUILD_TYPE="SHARED"
>else()
>BUILD_TYPE="STATIC"
>endif()
>find_package(XXX ${BUILD_TYPE})
>find_package(YYY ${BUILD_TYPE})
>find_package(ZZZ ${BUILD_TYPE})
>...
> 
> 
> It seems that this does not exist? I could also not find a
> good workaround. The best I can find is to use 'NAMES' and
> add the static or shared library names manually.
> 
> This is not very suitable, because I have a project with more
> than 30 dependencies. The project should either build (fully)
> static or (fully) shared. I can not easily maintain lists of
> 30 static and shared library names on several platforms.
> 
> Is there a solution or good workaround?
> 
> All the best,
> 
>Mario Emmenlauer
> 
> 
> (1) https://cmake.org/pipermail/cmake/2012-September/052059.html
> (2) https://cmake.org/pipermail/cmake/2010-December/041326.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

-- 

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

Re: [CMake] looking for 2 features to help pkg-config pc files

[P F via CMake]

The BCM(boost cmake modules) has `bcm_auto_pkgconfig` which will generate the 
pkgconfig file from a target, including the “Require” variable:

http://bcm.readthedocs.io/en/latest/src/BCMPkgConfig.html#bcm-auto-pkgconfig 


It utilizes the `INTERFACE_PKG_CONFIG_NAME` property to generate the pkgconfig 
names for the dependent targets:

http://bcm.readthedocs.io/en/latest/src/BCMProperties.html#interface-pkg-config-name
 


Currently, it doesn't coordinate with FindPkgConfig’s imported targets yet, so 
you will need to manually inject the name. However, when using 
`bcm_auto_export` it will export the property, so that when users finds the 
dependency with `find_package`, it knows the corresponding pkgconfig module.

> On Mar 27, 2018, at 7:19 AM, suzuki toshiya  > wrote:
> 
> Hi all,
> 
> I'm looking for 2 features to generate pkg-config pc files.
> I already wrote something, but some experts advised that there
> would be many people trying to do such, and there might be existing
> solution. If such functions are already included in cmake's
> official modules, please let me know. Of course, combination
> of existing functions would be OK.
> 
> function 1)
> ---
> 
> ...is trying to find an available pkg-config module name from a
> list of several candidates. the typical usecase would be a
> search of libjpeg by pkg-config (libjpeg? libjpeg8? libjpeg8-turbo?
> libjpeg9? libjpeg62? ...). getting a name of module is important
> to write "Require" variable of pc file.
> 
> there is already pkg_search_module() searching an available module
> from a list, but it does not return the name of found module.
> thus it cannot help to write "Require" variable.
> 
> what I wrote is something like this.
> 
> #
> # PKG_SEARCH_AVAILABLE_MODULE([var-name-of-found-module] [modules])
> #
> # there is pkg_search_module(), but it does not clarify
> # which module was found.
> #
> # this function does not set xxx_CFLAGS xxx_LIBS etc.
> #
> # use like:
> # PKG_SEARCH_AVAILABLE_MODULE(PC_LIBJPEG
> "libjpeg;libjpeg8-turbo;libjpeg8;libjpeg9;libjpeg62")
> #
> function(PKG_SEARCH_AVAILABLE_MODULE _found_pkg pkg_list)
>  set(_PKG_FOUND FALSE)
>  foreach(_pkg IN LISTS pkg_list)
>pkg_check_modules(_PKG "${_pkg}")
>if (_PKG_FOUND)
>  set("${_found_pkg}_FOUND" TRUE PARENT_SCOPE)
>  set("${_found_pkg}_MODULE_NAME" "${_pkg}" PARENT_SCOPE)
>  return()
>endif()
>  endforeach(_pkg)
> endfunction(PKG_SEARCH_AVAILABLE_MODULE)
> 
> function 2)
> ---
> ...makes something like LDFLAGS + LIBS from the pathnames of libraries.
> some library finders of cmake do not return "-L/xxx -lyyy" values
> but returns "/xxx/libyyy.so". pkg-config has some difficulties
> to hold such raw pathnames of the libraries (e.g. pkg-config
> use "Libs" variable for both of static and shared linking,
> thus having "libxxx.a" or "libxxx.so" explicitly is not good),
> so, the translation from "/xxx/libyyy.so" to "-L/xxx -lyyy".
> 
> what I wrote is something like this:
> 
> #
> # MAKE_LDFLAGS_FROM_LIBPATH([var-ldflags+libs] [libpath])
> #
> function(MAKE_LDFLAGS_FROM_LIBPATHS _ldflags _libpaths)
>  foreach(_libpath IN LISTS _libpaths)
>string(REGEX REPLACE "/[^/]*$" "" _libdir "${_libpath}")
> 
>string(REGEX REPLACE "^.*/" "" _lib "${_libpath}")
>string(REGEX REPLACE
> "(\\${CMAKE_STATIC_LIBRARY_SUFFIX}|\\${CMAKE_SHARED_LIBRARY_SUFFIX})$" "" _lib
> "${_lib}")
>string(REGEX REPLACE "^lib" "" _lib "${_lib}")
> 
>set(__ldflags "${__ldflags} ${CMAKE_LIBRARY_PATH_FLAG}${_libdir}
> ${CMAKE_LINK_LIBRARY_FLAG}${_lib}")
>  endforeach(_libpath)
>  set("${_ldflags}" "${__ldflags}" PARENT_SCOPE)
> endfunction(MAKE_LDFLAGS_FROM_LIBPATH)
> 
> Regards,
> mpsuzuki
> 
> -- 
> 
> 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

Kit