[CMake] Generating libtool file with CMake
Hi ! I'm trying to port the LibVMI project from autotools to CMake: https://github.com/libvmi/libvmi/pull/674 One of the problems I have is to generate a libtool libvmi.la file, like autotools is already doing. So far I have found this module on CMake wiki: https://gitlab.kitware.com/cmake/community/wikis/contrib/macros/LibtoolFile But it seems a bit old. CMake Error at cmake/modules/Libtool.cmake:9 (GET_TARGET_PROPERTY): The LOCATION property may not be read from target "vmi_shared". Use the target name directly with add_custom_command, or use the generator expression $, as appropriate. Call Stack (most recent call first): libvmi/CMakeLists.txt:127 (create_libtool_file) I found an updated version of this script on the GNU Radio project: https://github.com/gnuradio/gnuradio/blob/master/cmake/Modules/CMakeMacroLibtoolFile.cmake But again, another error: CMake Error: Error evaluating generator expression: $ Expression syntax not recognized. -> Can the CMake community help me a bit to generate this libtool file on a recent CMake release ? Thanks ! -- Mathieu Tarral Sent with ProtonMail Secure Email. -- 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] INTERFACE_LINK_LIBRARIES/LINK_INTERFACE_LIBRARIES
In other words, when providing the EXPORT_LINK_INTERFACE_LIBRARIES flag for exported targets (in main project that was changed to CMP0022 NEW), I was expecting the IMPORTED_LINK_INTERFACE_LIBRARIES property set in the .cmake file so that projects that import it (with CMP0022 OLD) can see it. Instead, I am only seeing the INTERFACE_LINK_LIBRARIES property set. On Fri, Nov 9, 2018 at 1:58 PM Hendrik Greving < hendrik.greving@gmail.com> wrote: > If CMP0022 is set to new, since project is still using > LINK_INTERFACE_LIBRARIES I have added EXPORT_LINK_INTERFACE_LIBRARIES to > install(EXPORT) and export() calls. Looking at the generated exported cmake > files, I only see the INTERFACE_LINK_LIBRARIES link property set. There are > downstream projects that are using the previously mentioned project > importing targets from it. These downstream projects still have CMP0022 set > to OLD. Will this work? My understanding is that these downstream projects > now don't see the linked libraries since they will ignore > INTERFACE_LINK_LIBRARIES? > > Is it possible to achieve both, and have the main project generate the > LINK_INTERFACE_LIBRARIES > properties with CMP0022 set to NEW? > -- 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
[CMake] INTERFACE_LINK_LIBRARIES/LINK_INTERFACE_LIBRARIES
If CMP0022 is set to new, since project is still using LINK_INTERFACE_LIBRARIES I have added EXPORT_LINK_INTERFACE_LIBRARIES to install(EXPORT) and export() calls. Looking at the generated exported cmake files, I only see the INTERFACE_LINK_LIBRARIES link property set. There are downstream projects that are using the previously mentioned project importing targets from it. These downstream projects still have CMP0022 set to OLD. Will this work? My understanding is that these downstream projects now don't see the linked libraries since they will ignore INTERFACE_LINK_LIBRARIES? Is it possible to achieve both, and have the main project generate the LINK_INTERFACE_LIBRARIES properties with CMP0022 set to NEW? -- 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] CPack disable build all
Le ven. 9 nov. 2018 à 17:22, DKLind a écrit : > I have a very large project where each sub-project creates a debian > package. > > When "make/ninja package" is specified, it performs a "make/ninja all" > before packaging. I would prefer to perform a "make/ninja all" myself > before > I doing a "make/ninja package". > > I want to create a package for just one target. I can use "cpack -D > CPACK_COMPONENTS_ALL=" to do this but, CPack takes a long time to > create the package. I can only surmise that CPack is building everything in > the background, as there is no output. If I have everything build BEFORE i > run "cpack -D CPACK_COMPONENTS_ALL=", it completes in seconds. > I'm almost sure that when invoked on itself like: cpack -G TGZ cpack does not build at all. cpack does install but AFAIK it does not trigger the build. you can try: ninja clean cpack -V -G TGZ and I'm pretty sure CPack will fail because it won't find the expected bits to be installed precisely because they are not built. Note that using "-V" verbose option of CPack you'll more traces of what CPack does. > Is it possible to disable CPack from building everything? > If you observe that could you send us a stripped down project that exhibit this behavior? -- Eric -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] CPack disable build all
I have a very large project where each sub-project creates a debian package. When "make/ninja package" is specified, it performs a "make/ninja all" before packaging. I would prefer to perform a "make/ninja all" myself before I doing a "make/ninja package". I want to create a package for just one target. I can use "cpack -D CPACK_COMPONENTS_ALL=" to do this but, CPack takes a long time to create the package. I can only surmise that CPack is building everything in the background, as there is no output. If I have everything build BEFORE i run "cpack -D CPACK_COMPONENTS_ALL=", it completes in seconds. Is it possible to disable CPack from building everything? -- Sent from: http://cmake.3232098.n2.nabble.com/ -- 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] dependencies of cross compiliations
There are two options. Each with pros and cons. The first what you are doing now, except you use external project https://cmake.org/cmake/help/v3.12/module/ExternalProject.html to build the host tools instead of add_custom_command. It otherwise has all the cons you mention, but are they significant (this is a question that is different for each project)? Going back to the manual build for host before the target isn't bad, though it is harder to teach. The second is to use a package/dependency manager to setup your build environment with all tools. In this approach the host tools would be in a separate source control repository and the package manager will download the latest binaries. Conan.io comes to mind as a tool to do this, but there are at least a dozen others that you can choose from (or write your own if you have a year to spend) . This approach is much more complex, but these systems offer many other features that are often compelling. I would recommend you spend some time researching the package/dependency manager tools available. It is likely that you (or your team) will look at some feature completely unrelated to your question and say "This is a good solution to our problem". At that point your question changes from "how do I best make cmake do this" to "how do I do this in my new package manager". If after a review nothing stands out, your approach is perfectly fine, the only question is it worth tweaking. -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Torsten Robitzki Sent: Friday, November 9, 2018 3:04 AM To: cmake@cmake.org Subject: [CMake] dependencies of cross compiliations Hi, I hope this question was not asked before. I work in the embedded field and there it is usually to have at least two different build platforms. The Host platform, where unit tests are build (and where CMake is running) and an embedded Target platform, where targets are build with a cross compiler. Sometimes such a system comes with self-written tools that are build and run on the Host platform to build a target for the embedded Target platform (adding meta data to a binary to be used by a bootloader for example). Usually I have two different build folders, one for the Host platform and one for the Target platform, using different calls to cmake to choose from a set of tools and targets. But when using this approach, it is necessary that the Host platform build ran before the Target platform build, so that tools that are required for the Target platform are build during the Host target build. One solution I’ve came up with, is to build the required tools during the Target platform build, using an add_custom_target() to invoke the Target compiler directly. This works fine, as long as the tools are basically build just out of a couple of files. What would be the „CMake-Way“ to add the tools (that have to be build on the Target platform) as dependency to targets that have to be build for the Target (cross compile) platform? Kind regards and thanks in advance, Torsten -- 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] [cmake-developers] module proposal: PreventInSourceBuilds
# disallow in-source builds
if("${srcdir}" STREQUAL "${bindir}")
if(srcdir STREQUAL bindir)
HTH
Eike
--
--
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
[CMake] dependencies of cross compiliations
Hi, I hope this question was not asked before. I work in the embedded field and there it is usually to have at least two different build platforms. The Host platform, where unit tests are build (and where CMake is running) and an embedded Target platform, where targets are build with a cross compiler. Sometimes such a system comes with self-written tools that are build and run on the Host platform to build a target for the embedded Target platform (adding meta data to a binary to be used by a bootloader for example). Usually I have two different build folders, one for the Host platform and one for the Target platform, using different calls to cmake to choose from a set of tools and targets. But when using this approach, it is necessary that the Host platform build ran before the Target platform build, so that tools that are required for the Target platform are build during the Host target build. One solution I’ve came up with, is to build the required tools during the Target platform build, using an add_custom_target() to invoke the Target compiler directly. This works fine, as long as the tools are basically build just out of a couple of files. What would be the „CMake-Way“ to add the tools (that have to be build on the Target platform) as dependency to targets that have to be build for the Target (cross compile) platform? Kind regards and thanks in advance, Torsten -- 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
