Hi Lars: On 2019-01-22 12:05-0000 Lars wrote:
Alan, Thank you very much for the response.
You are welcome.
Our 'foo' package does not use CMake. That means there is no build-system to produce the foo-config.cmake file, the file is manually created. The file does allow different projects to import the target from 'foo' package that has been installed. However, we need to include the library and config file in CPack installer and who is responsible for that task? We are using Qt5 config mode to import targets like you describe in development context and it works. However, to setup packaging system (CPack) we need to perform the Install(..) command so that the necessary Qt5 targets are included in the installer (MSI and RPM). We cannot require the customer to install a 2GB Qt5 installer for a few libraries. In that context it is unclear who\when\how should perform the installation.
As you are probably already aware, the Qt5 software produces their "*-config.cmake" in a non-CMake way. And it appears you are attempting to follow that method for your own "foo" package case. I applaud that attempt since that end result should make life much easier for users of your foo package that do use CMake. However, now I hear you are using CPack for foo as well. So maybe it is time to bite the bullet and move foo to a cmake build (which should make your life much simpler for creating both a working "foo-config.cmake" file and a working CPack configuration.) I specifically used the term "bite the bullet" because changing build systems for any large software project with many different executables and libraries is obviously not a trivial task. But I assure you the end goal of having a complete CMake-based build, test, and CPack system is worth the pain of the transition. But I would also advise you it is possible to get from your present state to that goal in small manageable steps that are not painful at all because partially implemented CMake-based build systems normally happily coexist with other build systems. To take an example of such a soft (and completely unplanned) transition to CMake (from more than a decade ago now) in the PLplot case we had a mature autotools-based build system that was mostly good enough "except for a few nagging problems...." So out of curiosity more than anything else I started a hobby project of implementing the build of just one of our smaller libraries with CMake. And that proved to be trivial (it only took a half an hour or so to learn what I needed about CMake starting from zero knowledge), and the resulting library built much faster. Following up on that initial promising result I quickly (with some substantial help from other PLplot developers at the time who were interested in learning about CMake) extended that hobby build system to more and more of our libraries and executables. Until within a month or so of me starting this "hobby" this self-organized group of developers for our CMake-based build system was producing the same libraries, shared-objects, and executables as our "standard" autotools-based build system. But that configuration was much easier to understand than for our standard build system, and both the configuration and build was much faster than for the autotools case. As a result we "got serious" and for the next month or so extended the work to support both PLplot testing and the installed version of PLplot to essentially complete the project. For a year after that we maintained both the CMake-based and autotools-based build systems, but interest in the latter dropped so fast that at the end of that year we completely removed all traces of our autotools-based build system from our source tree, and we never regretted that decision. Note, this transition to a CMake-based build system would likely not have ever happened if we attempted to plan it from the start. Instead, treating it like a learning hobby motivated me and the rest of our development group a lot, and we achieved a very fast and non-painful transition as a result. Of course, you may reply that the "foo" case is completely different and you are completely happy with your present build system for that software. If so, that is fine. However, if you have some nagging doubts about that build system (for example, some inconveniences when implementing the "foo-config.cmake" file, configuring CPack, or ultimately (if you are interested in testing "foo" configuring CTest) then perhaps it is time for you to start a possible soft transition to a CMake-based build system for "foo" as a hobby style of project without the type of "planning" that often kills such potentially useful projects dead. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -- 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