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

Jon Turney via Cygwin-apps <[email protected]> Wed, 4 Feb 2026 20:26:02 +0000
Newsgroups gmane.os.cygwin.applications
Message-ID <[email protected]>
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.

>> 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.)