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
