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