Re: [CMake] hear hear
On Tuesday 20 December 2011, Benjamin Eikel wrote: Hello Alexander, Am Montag, 19. Dezember 2011 um 21:19:04 schrieb Alexander Neundorf: On Monday 19 December 2011, Benjamin Eikel wrote: Hello Alexander, Am Montag, 12. Dezember 2011, 21:51:54 schrieb Alexander Neundorf: Here is an example which shows just that: https://projects.kde.org/projects/kde/kdeexamples/repository/revision s/ ma st er/show/buildsystem/HowToInstallALibrary It's not final yet, i.e. I'll work on improving it in the next weeks. thank you very much for this example project. It helped me a lot to understand especially the EXPORT usage. I know that you wrote that the project is not finished yet, but allow me to ask a question: In the example/CMakeLists.txt: Is line 5, which calls include(FindPackageHandleStandardArgs), really needed? I think if BAR_FOUND would be checked, it should be called. Line 6 is commented out because it relies on a feature in cmake 2.8.3, but when I committed the example I made it depend only on 2.6.4. Does that answer your question ? Yes, it's clear now. I would greatly appreciate it if you could extend the example, or provide a second example, that uses an external library. So for example a library Foo depending on LibXml2. Some functionality of Foo depends on whether LibXml2 was found or not. Therefore it creates Foo_Config.h with configure_file defining something like LIB_XML2. I would like to see how this could be correctly installed and found by an application using Foo. Would it be simply adding the config header file to the set of exported header files? I'd put that information into the installed FooConfig.cmake, something like: set(FOO_HAS_LIBXML2_FEATURES TRUE) Okay. Then it would be possible to set compile definitions depending on this variable. But it would only work for projects using CMake, too. The header file could be used by projects using any build system. You can put the information of course in both places. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] hear hear
Hello Alexander, Am Montag, 12. Dezember 2011, 21:51:54 schrieb Alexander Neundorf: Here is an example which shows just that: https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/mast er/show/buildsystem/HowToInstallALibrary It's not final yet, i.e. I'll work on improving it in the next weeks. thank you very much for this example project. It helped me a lot to understand especially the EXPORT usage. I know that you wrote that the project is not finished yet, but allow me to ask a question: In the example/CMakeLists.txt: Is line 5, which calls include(FindPackageHandleStandardArgs), really needed? I think if BAR_FOUND would be checked, it should be called. But in the current version only BAR_INCLUDES, BAR_LIBRARIES, and BAR_VERSION are used. These variables should be set by BarConfig.cmake, shouldn't they? I would greatly appreciate it if you could extend the example, or provide a second example, that uses an external library. So for example a library Foo depending on LibXml2. Some functionality of Foo depends on whether LibXml2 was found or not. Therefore it creates Foo_Config.h with configure_file defining something like LIB_XML2. I would like to see how this could be correctly installed and found by an application using Foo. Would it be simply adding the config header file to the set of exported header files? Kind regards Benjamin Eikel -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] hear hear
On Monday 19 December 2011, Benjamin Eikel wrote: Hello Alexander, Am Montag, 12. Dezember 2011, 21:51:54 schrieb Alexander Neundorf: Here is an example which shows just that: https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/ma st er/show/buildsystem/HowToInstallALibrary It's not final yet, i.e. I'll work on improving it in the next weeks. thank you very much for this example project. It helped me a lot to understand especially the EXPORT usage. I know that you wrote that the project is not finished yet, but allow me to ask a question: In the example/CMakeLists.txt: Is line 5, which calls include(FindPackageHandleStandardArgs), really needed? I think if BAR_FOUND would be checked, it should be called. Line 6 is commented out because it relies on a feature in cmake 2.8.3, but when I committed the example I made it depend only on 2.6.4. Does that answer your question ? I would greatly appreciate it if you could extend the example, or provide a second example, that uses an external library. So for example a library Foo depending on LibXml2. Some functionality of Foo depends on whether LibXml2 was found or not. Therefore it creates Foo_Config.h with configure_file defining something like LIB_XML2. I would like to see how this could be correctly installed and found by an application using Foo. Would it be simply adding the config header file to the set of exported header files? I'd put that information into the installed FooConfig.cmake, something like: set(FOO_HAS_LIBXML2_FEATURES TRUE) Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] hear hear
Hello Alexander, Am Montag, 19. Dezember 2011 um 21:19:04 schrieb Alexander Neundorf: On Monday 19 December 2011, Benjamin Eikel wrote: Hello Alexander, Am Montag, 12. Dezember 2011, 21:51:54 schrieb Alexander Neundorf: Here is an example which shows just that: https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/ ma st er/show/buildsystem/HowToInstallALibrary It's not final yet, i.e. I'll work on improving it in the next weeks. thank you very much for this example project. It helped me a lot to understand especially the EXPORT usage. I know that you wrote that the project is not finished yet, but allow me to ask a question: In the example/CMakeLists.txt: Is line 5, which calls include(FindPackageHandleStandardArgs), really needed? I think if BAR_FOUND would be checked, it should be called. Line 6 is commented out because it relies on a feature in cmake 2.8.3, but when I committed the example I made it depend only on 2.6.4. Does that answer your question ? Yes, it's clear now. I would greatly appreciate it if you could extend the example, or provide a second example, that uses an external library. So for example a library Foo depending on LibXml2. Some functionality of Foo depends on whether LibXml2 was found or not. Therefore it creates Foo_Config.h with configure_file defining something like LIB_XML2. I would like to see how this could be correctly installed and found by an application using Foo. Would it be simply adding the config header file to the set of exported header files? I'd put that information into the installed FooConfig.cmake, something like: set(FOO_HAS_LIBXML2_FEATURES TRUE) Okay. Then it would be possible to set compile definitions depending on this variable. But it would only work for projects using CMake, too. The header file could be used by projects using any build system. Thank you! Kind regards Benjamin -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] hear hear
On Tuesday, 6. December 2011, 17:27:47, Daniel Dekkers wrote: On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: I think if the CMake community took a vote we could probably come up with an Exemplar Find*.cmake file that is good for someone trying to develop a new one. Yes please. And I think in general that is true. Of course it is more interesting and often more urgent to spend time on exotic problems. But there are these basics that are missing in the documentation. Like,.. this works in 99% of the cases, we, CMake, advise you to do this. If you don't, you are making life hard on yourself and you are more or less on your own. Something like: 1) a single executable 2) a single executable linked to a lib built from source 3) different executables using the same lib built from source 4) a single executable linked to a binary lib (with the aid of a find module) ... n) multiple executables linked to multiple libraries (linked to third-party libraries), some static, some dynamic, some with their own CMake builds, some without, on different platforms. Auch. n+1) making anything work with Xcode I would like that, too. Also, it would be nice if the example would include a *Config.cmake (and *Version.cmake) file. What I notice with several projects is that the *config.cmake mechanism for finding out about a package is still largely ignored and each projects rolls out its own Find*.cmake file instead, which dependent projects than copy into their source tree. Raising the awareness for the *Config.cmake style of making your package easy to find would certainly be a good thing. Cheers, Johannes -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] hear hear
On Monday 12 December 2011, Johannes Zarl wrote: On Tuesday, 6. December 2011, 17:27:47, Daniel Dekkers wrote: On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: I think if the CMake community took a vote we could probably come up with an Exemplar Find*.cmake file that is good for someone trying to develop a new one. Yes please. And I think in general that is true. Of course it is more interesting and often more urgent to spend time on exotic problems. But there are these basics that are missing in the documentation. Like,.. this works in 99% of the cases, we, CMake, advise you to do this. If you don't, you are making life hard on yourself and you are more or less on your own. Something like: 1) a single executable 2) a single executable linked to a lib built from source 3) different executables using the same lib built from source 4) a single executable linked to a binary lib (with the aid of a find module) ... n) multiple executables linked to multiple libraries (linked to third-party libraries), some static, some dynamic, some with their own CMake builds, some without, on different platforms. Auch. n+1) making anything work with Xcode I would like that, too. Also, it would be nice if the example would include a *Config.cmake (and *Version.cmake) file. Here is an example which shows just that: https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem/HowToInstallALibrary It's not final yet, i.e. I'll work on improving it in the next weeks. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] hear hear
On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: I think if the CMake community took a vote we could probably come up with an Exemplar Find*.cmake file that is good for someone trying to develop a new one. Yes please. And I think in general that is true. Of course it is more interesting and often more urgent to spend time on exotic problems. But there are these basics that are missing in the documentation. Like,.. this works in 99% of the cases, we, CMake, advise you to do this. If you don't, you are making life hard on yourself and you are more or less on your own. Something like: 1) a single executable 2) a single executable linked to a lib built from source 3) different executables using the same lib built from source 4) a single executable linked to a binary lib (with the aid of a find module) ... n) multiple executables linked to multiple libraries (linked to third-party libraries), some static, some dynamic, some with their own CMake builds, some without, on different platforms. Auch. n+1) making anything work with Xcode Buy the book is a good response of course. But people don't do that, until 3 months later. Thanks, Daniel -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] hear hear
On 6 December 2011 16:27, Daniel Dekkers d.dekk...@cthrough.nl wrote: On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: I think if the CMake community took a vote we could probably come up with an Exemplar Find*.cmake file that is good for someone trying to develop a new one. Yes please. And I think in general that is true. Of course it is more interesting and often more urgent to spend time on exotic problems. But there are these basics that are missing in the documentation. It's a great idea and I've been suggesting and looking for best practices for long time: http://www.cmake.org/pipermail/cmake/2010-March/035596.html I'd add also: Find*.cmake modules should be documented separately (separate chapters/pages) from the main documentation. The current documentation is already very long and navigating it has become difficult. Adding guidelines for Find*.cmake modules will make it close to impossible to use. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] hear hear
On Tuesday 06 December 2011, Mateusz Łoskot wrote: On 6 December 2011 16:27, Daniel Dekkers d.dekk...@cthrough.nl wrote: On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: I think if the CMake community took a vote we could probably come up with an Exemplar Find*.cmake file that is good for someone trying to develop a new one. Yes please. And I think in general that is true. Of course it is more interesting and often more urgent to spend time on exotic problems. But there are these basics that are missing in the documentation. It's a great idea and I've been suggesting and looking for best practices for long time: http://www.cmake.org/pipermail/cmake/2010-March/035596.html I'd add also: Find*.cmake modules should be documented separately (separate chapters/pages) from the main documentation. The current documentation is already very long and navigating it has become difficult. Do you mean the book or the man/html pages ? For man/html-pages, additionally to the all-in-one cmake.html (or man page), there are also splitted man/html-pages: man cmakemodules man cmakecommands man cmakeprops man cmakepolicies Is that what you mean ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
