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

Dear Marc, this is a pretty neat idea! Let me quickly recapitulate: the library prefixes and suffixes for multiple platforms are: | static| shared | prefix|suffix| prefix| suffix

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

Yes. Seems OK. For Windows, if libraries are all your owns, you can manage this by relaying on a specific prefix for static libraries. A commonly adopted naming is to add prefix "lib" for static libraries. Now, if you add to rely on external libraries, I don't see any general solution. On

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

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,

Re: [CMake] [proposal] Support for modern CMake

On 20 March 2018 at 21:52, Alexander Neundorf wrote: > On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote: > ... >> Why I can not write: >> >> target_use(app Boost::system Boost::filesystem) >> >> or >> >> target_use_targets(app Boost::system Boost::filesystem) >> >> and,

Re: [CMake] [proposal] Support for modern CMake

On 22 March 2018 at 16:51, Brad King wrote: > On 03/22/2018 10:17 AM, Mateusz Loskot wrote: >> It seems folks generally agree there is need for porcelain API. >> It's a pity it's been 5+ years and it is still waiting for implementation. > > [...] > The main driving factor

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

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

Re: [CMake] [proposal] Support for modern CMake

On 03/22/2018 10:17 AM, Mateusz Loskot wrote: > It seems folks generally agree there is need for porcelain API. > It's a pity it's been 5+ years and it is still waiting for implementation. For reference, there were several discussions. Some of them were here: * "Setting include directories via

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

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

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

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

Re: [CMake] Adding ignored tests to CTest XML output

On Thu, Mar 22, 2018 at 4:08 AM, Kai Wolf wrote: > when adding some ignored tests into the CTestCustom.cmake file via the > variable CTEST_CUSTOM_TESTS_IGNORE, I'd expect that those ignored tests > will also be written into the XML output file generated by CTest, so that >

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

Another possibility is to customize the variable CMAKE_FIND_LIBRARY_SUFFIXES. For example, on linux: * shared only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".so") * static only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".a") On Windows, it is more problematic because static and "import" shared libraries have

[CMake] Adding ignored tests to CTest XML output

Hi all, when adding some ignored tests into the CTestCustom.cmake file via the variable CTEST_CUSTOM_TESTS_IGNORE, I'd expect that those ignored tests will also be written into the XML output file generated by CTest, so that Jenkins or Teamcity is able to visualize this information. However, it

Re: [CMake] Custom Configurations and CMAKE__FLAGS__INIT

It turns out, as of CMake 3.11, this works. Thanks to Beren Minor's commit 48f7e2d3, CMake 3.11 has a new CMakeInitializeConfigs.cmake module that handles all _INIT variables, even custom configuration ones, correctly. Yay! [0]

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

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 >

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

Our why doesn't cmake set a long needed standard here of .dll.lib and be done with this nonsense? On Thu, Mar 22, 2018, 11:58 PM P F via CMake wrote: > Why not install shared libraries in one location and static libraries in > another? > > > On Mar 21, 2018, at 4:55 AM, Mario

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

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

Re: [cmake-developers] INTERFACE IMPORTED example

On 03/21/2018 06:01 PM, Craig Scott wrote: > I swear I asked this a while back and there was an example given Maybe here: * https://gitlab.kitware.com/cmake/cmake/merge_requests/1581 > Does anyone know of a specific example scenario where an > INTERFACE IMPORTED library is the right choice over

[Cmake-commits] CMake branch, master, updated. v3.11.0-rc4-300-gd78d750

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via d78d750c04f9d928afd7f29dcb66f854dc3bbe2b (commit) via

[Cmake-commits] CMake branch, master, updated. v3.11.0-rc4-313-g9f2ec9d

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 9f2ec9d241b58aa2184c11bd6d863885d1fcdec7 (commit) via

Re: [cmake-developers] INTERFACE IMPORTED example

On Thu, Mar 22, 2018 at 10:37 PM, Brad King wrote: > On 03/21/2018 06:01 PM, Craig Scott wrote: > > I swear I asked this a while back and there was an example given > > Maybe here: > > * https://gitlab.kitware.com/cmake/cmake/merge_requests/1581 Yes, that was it, thanks.

[Cmake-commits] CMake branch, master, updated. v3.11.0-rc4-311-g82df2fe

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 82df2fe17e81fa4efa9717ec9d83d2915d56aa33 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.11.0-rc4-314-g2614335

VERSION_MINOR 11) -set(CMake_VERSION_PATCH 20180322) +set(CMake_VERSION_PATCH 20180323) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [cmake-developers] CDash - upload Test.xml 500 Error

On Thu, Mar 22, 2018 at 2:09 PM, Michal Wozniak wrote: > I am getting a 500 Internal Server Error during the uploading of the > Test.xml file. > > Is there something I need to enable on my CDash instance? > It should work out of the box. See if you can find more