Re: [PATCH] Update c-ares for including config scripts for CMake

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