Hello friends! The points brought up are good. However, I have some experience with CMake's edge cases (due to using Gentoo) so I feel like I should give my opinion on some of the solutions. The solutions are good, I just think it is important to indicate that building truly cross platform code with CMake still seems to be an open problem.
Specifically, if anyone has anything to add on how to use CMake to find Windows dependencies, I am looking for help in that area. On Tue, Nov 21, 2017 at 5:36 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > 21.11.2017, 13:45, "Johannes Zarl-Zierl" <johannes.zarl-zi...@jku.at>: >> Hi, >> >> I thought you might want some context for the suggestions: >> >> On Dienstag, 21. November 2017 11:45:43 CET Konstantin Tokarev wrote: >>> 1) add instruction how to install dependencies >> >> This is what many/most projects do, and it works reasonably well. >> Advantages: >> - You don't clutter your project with dependencies >> - People on each platform already know how to install dependencies >> - You don't complicate things for package maintainers >> Disadvantages: >> - No automatic dependency resolution >> This is really the best solution on Unix-based operating systems and will work in the vast majority of cases. The one sticking point is that most FOSS libraries are not distributed by installer for Windows anymore, and it is extremely likely you will need to bundle your dependencies with your project when targeting Windows. Also, sometimes fringe distributions will not have their library install locations in the paths checked by CMake. Usually they will have pkg-config configured properly, and you can find the libraries and headers that way. >>> 2) use hand-made script or more complex solution to automate dependency >>> installation, or >> >> Hand-made scripts are often a maintenance nightmare and hard to get right for >> all platforms. The One True Way(TM) would be a so-called "super-build", i.e. >> a >> CMake project that uses external_project() to build your project along with >> its dependencies. > > FWIW I've seen many projects that provide scripts or one-liners how to > install all > dependencies on popular systems, and if things are readily available or > otherwise pre-built > and downloadable from central place, it's not hard to maintain, at least when > number of > dependencies is small > >> >>> 3) avoid using find_package() st all >> >> That's the first time I've heard that suggestion. I'm not sure if this will >> ease your pain ;-) > > I've meant by using things like ExternalProject, or from your point 4, or when > using other metabuilders. When all dependencies are in known locations, > you don't really need to use find_package anymore. > > Though It may be handy though if you allow building with both external and > internal dependencies, e.g. if you develop open source project distributors > will be reluctant to include it if it can use bundled dependencies only. > Using ExternalProject and a dependency fetching script suffer from the same problem. It is very easy to implement these things insecurely, and it makes your software hard to package for Linux distributions. When I see a trendy new project that prominently features a "curl | sh" line on its webpage I shudder and, try as I might, I usually write it off in my mind. Besides those lines sometimes not having "https://"; in them, installing software outside of your package manager will eventually lead to a slew of problems (developers that focus on one or two projects may never experience those problems, but that is almost entirely luck). I think there are two major examples I can give: 1) Haskell's Cabal would fetch code (some immediately executed but also the packages) over HTTP with no authentication, and that code would often run as root. This has only recently been fixed, but I still feel like I need to double check myself. 2) Sage Math bundles, I think, 80 pieces of software with it, and has its own package management system. It builds GCC to build itself! For some of the problems that this causes, see https://bugs.gentoo.org/201321. I do recognize that sometimes distributions simply won't have the libraries you need. In that case, I recommend leaving it to the user to find a way to get those libraries. Personally I install them to ~/.local and add them to the search paths, but this is hard to do with CMake. Sometimes users will find newer libraries in a backports repository. >> >> 4) Shipping the dependency with your project (not using external_project) >> This can sometimes be useful, but you should carefully consider the >> implications beforehand to see if it's worth it for your project. As a rule >> of >> thumb: don't do this if the dependency is readily available and/or big. >> I dislike doing this on principle but it's pretty common for Windows. Sticking a deps/ directory in your repository with precompiled libraries and the header files is an easy way to reduce the burden for potential contributors. I have also seen instructions for building packages and specifying their location manually. Should you do this, GPG-signing your commits would be an especially good idea. Cheers, R0b0t1 -- 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
