Hello, perhaps, you may also check how a particular package is handled by linux distributions, MSYS2 or others. For example, this is how it is handled by arch linux or other distros:
https://gitlab.archlinux.org/archlinux/packaging/packages/c-ares/-/blob/main/PKGBUILD?ref_type=heads and it is also using CMake, as you can see. This probably means that somebody has already faced this issue and he has already evaluated which build system was the best choice for a particular package. Usually, I prefer to use CMake or Meson (if they are supported) over autotools with cygport, just because they avoid the autoreconf stage and they tipically provide extra features like c-ares did, but that's just my personal opinion. Sincerely, Carlo Bramini. Il giorno mer 4 feb 2026 alle ore 22:33 Brian Inglis via Cygwin-apps <[email protected]> ha scritto: > > On 2026-02-04 13:26, Jon Turney via Cygwin-apps wrote: > > On 03/02/2026 12:37, Carlo B. via Cygwin-apps wrote: > > [...] > >>> Could you please summarize the differences in the files the -devel > >>> packages > >>> provide when built under cmake, > >> I attached two screenshots to this email with the differences > >> inspected with winmerge. > >> Into the first screenshot, you can see the differences between the files. > >> As I have written in the previous email, the share directory is > >> missing into my devel package because I moved it in a new package into > >> the "Doc" category. > >> The devel package created from CMake includes also the "cmake" > >> directory with the scripts needed by this tool. > >> The other differences are just "fake", as you can see from the second > >> screenshot. > >> > >>> and could we just add these to the contents of > >>> the -devel package without using that build mechanism, or would we have > >>> to build > >>> and install twice each to get all artifacts? > >>> > >> I have no idea how the config script generated by CMake could be > >> compiled without CMake. > >> Actually, I don't understand why we should do it, since CMake creates > >> everything we need, including the .pc file. > > > > This sounds like a bug in the consumer (FlightGear Simulator, I guess, > > whatever > > that is), if it can't detect c-ares via the .pc file. > > [See 1.34.2 for package detection fixes that may be relevant.] > > >>> Advice required on ensuring that devel packages that support autotools > >>> and cmake > >>> and make and ninja are built appropriately to provide all of the > >>> components to > >>> do all of the above? > >>> > >>> Can we and should we do so when -devel packages also provide cmake > >>> support? > > > Well, I guess this is another example of why having multiple build systems > > is a > > bad idea. :) > > > > Generally, if upstream has a "preferred" build system, that's perhaps the > > one we > > should be using. (All though it's probably not worth the effort of changing > > whenever upstream changes it's mind...) > > > > But building everything with cmake, just so we can build everything else > > with > > cmake is not a good plan. > > > > (By which I mean: I'm pretty sceptical of the utility of CMake package > > config- > > files, since they can only be generated and consumed by CMake.) > > I gather that means you think we should not attempt to support both autoconf > and > cmake builds for packages which support both, and by default support autotools > as cygport defaults to using that, unless say, upstream supports both, prefers > cmake, and provides more of something useful in that package. > > In the case of this package Curl Asynchronous RESolver library, from the curl > team @haxx.se, why I picked it up, the "official" approach is autotools: > > https://www.mail-archive.com/[email protected]/msg01460.html > [predates [email protected]] > > and bug fixes for cmake issues implies it is still not as well supported. > > -- > Take care. Thanks, Brian Inglis Calgary, Alberta, Canada > > La perfection est atteinte Perfection is achieved > non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add > mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut > -- Antoine de Saint-Exupéry
