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

On 2026-02-02 06:24, Carlo B. wrote:
> I compiled FlightGear Simulator for CYGWIN and MinGW and I dicovered
> that the simgear component was not able to find c-ares library.
> 
> With reference to this message:
> https://cygwin.com/pipermail/cygwin-announce/2025-December/012721.html
> recently, c-ares has been updated to the latest version available at
> the time of writing, but it has been compiled by using autotools.
> As result, the development package does not include the config scripts
> for CMake.
> 
> So, I updated the script for cygport of c-ares for using CMake instead.
> Now, the development package also includes the config scripts for
> CMake and simgear has been able to find the library successfully.
> 
> I cloned the sources of the existing package script here:
> https://cygwin.com/cgit/cygwin-packages/c-ares/
> and created a patch file that you can find attached to this email.
> 
> At this address:
> https://github.com/carlo-bramini/packages-cygwin/tree/main/c-ares
> you can also find the modified cygport file with my precompiled libraries.
> 
> The changes can be resumed as:
> 1) Added inherit to cmake
> 2) Increased release number from 0 to 1
> 3) Added CYGCMAKE_ARGS. Note, I have not removed autotools arguments
> just to keep the patch smaller.
> 4) libcares_devel_CATEGORY is now "Devel".
> 5) I removed the man files from libcares_devel and I created a new
> libcares_doc as "Doc".
> 
> Into the above address of my packages-cygwin repository, you can also
> find updated packages for MinGW cross compilers, if you will want to
> upgrade them too.
> 
> I hope that all you and the maintainer of the c-ares packages will
> find this report useful.

Hi Carlo,

Forgot about rel -0 which was probably because the original update jump was 18 
releases so released in test status, but not upgraded to stable with a new rel -1.

Did this also build the utilities and run any tests?

Could you please summarize the differences in the files the -devel packages 
provide when built under cmake, 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?

More generally for other folks input:

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?

What about mingw64 packages?

Previously I think we have just been happy that packages built okay under the 
default mechanism, and only used cmake with make or ninja, depending on which 
worked to give the desired package(s).

[Sending with "highest" priority to see if MUAs make it more visible and that 
will gain more attention from others?]

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