3 ms·
With a non-standard mess on its own ... Perhaps, but not any that I have had problems with. E.g. an application that we distribute uses Qt, Boost, Berkeley DB
by danieldk 13y ago
With a non-standard mess on its own ...
Perhaps, but not any that I have had problems with.
E.g. an application that we distribute uses Qt, Boost, Berkeley DB XML, libxml2, libxslt, etc. Producing signed application bundles for OS X, MSI installers for Windows, and packages for Ubuntu has been nearly painless. And that's with clang on OS X, Visual C++ on Windows, and gcc on Linux. If it's easy to produce binaries on the three most popular platforms, with three different compilers, I don't see the problem.
We have tried autotools before. But it's a pain on Windows with Visual Studio. Let alone that I can quickly generate a Visual Studio project to do some debugging.
- matthiasv 13y agoSure, if you do the packaging for a restricted set of environments yourself, CMake certainly works fine. I do the same for a lot of projects and know what CMake is capable of. But when it comes to the differences between all those Linux distributions, the respective packager will be very glad to see that he can customize install prefixes (no, CMAKE_INSTALL_PREFIX is not enough) and use standard make targets. Your list of dependencies shows libraries that are well covered by the stock CMake modules but try getting a build variable that is not LIBS or CFLAGS from a library that can only be queried with pkg-config. Impossible.
- danieldk 13y agoBut when it comes to the differences between all those Linux distributions, That's a fair point. However, most often, I am more interested in accommodating the 99.8% of the population that uses Windows, OS X, or one of the major Linux distributions, than the tiny group that runs Sabayon and is able to get things compiled themselves if necessary.