[build-system] make libuca builds portable and reproducible

[NikolayZagainov]

Summary

This pull request modernizes libuca’s build and packaging infrastructure and
aligns its CMake, Meson and Conan configurations.

The previous build definitions had diverged over time. Some dependencies and
optional components were handled differently depending on the selected build
system, packaging relied on developer-machine assumptions, and clean builds on
new Linux or Windows environments were unnecessarily difficult.

This change establishes a common, reproducible build foundation for existing
libuca functionality and future binary camera plugins. It does not add a new
camera driver or change the public camera API.

Problems addressed

Before this change:

• CMake and Meson used different language standards, dependency versions and
  optional-component behavior.
• The deprecated GTK 2 GUI was built or probed by default, adding an obsolete
  dependency to otherwise headless installations.
• TIFF support was not consistently optional.
• Command-line tools could link against TIFF even when TIFF support was
  disabled.
• The Conan recipe contained outdated package metadata and dependency
  versions.
• Conan CI depended on an unpinned third-party action and an unspecified Conan
  version.
• CPack was fixed to RPM output instead of allowing the caller to select an
  appropriate package format.
• Plugin discovery matched complete paths too loosely and did not correctly
  handle plugin names containing _ or -, or versioned shared-library
  filenames.
• Enumerated camera-name lists were not released after counting network
  cameras.
• Multi-page TIFF output initialized some TIFF fields in the wrong order and
  did not restore per-page fields after TIFFWriteDirectory().

These issues made local builds, CI builds, binary packaging and installation on
clean machines behave differently.

Changes

Common build requirements

• Require CMake 3.16 or newer.
• Build as standard C11 without compiler-specific language extensions.
• Enable consistent warning levels for GCC and Clang.
• Raise the minimum GLib family version from 2.38 to 2.56 in both CMake and
  Meson.
• Require libtiff 4.3 or newer when TIFF support is enabled.

Optional components

• Disable the deprecated GTK 2 camera-control GUI by default.
• Keep the GUI available through an explicit build option.
• Make Meson require GTK only when the GUI is explicitly requested.
• Make TIFF linking conditional in the CMake command-line tools.
• Preserve the ability to build libuca without TIFF.
• Add build options for proprietary Ximea support without requiring the SDK in
  normal or CI builds.

The Ximea camera implementation itself is not included in this pull request.
Only the optional build configuration needed to keep proprietary SDKs out of
ordinary builds is introduced here.

CMake packaging

• Enable CTest through the standard include(CTest) mechanism.
• Make the CPack generator configurable instead of forcing RPM.
• Use TGZ as the portable default.
• Enable Debian shared-library dependency calculation when DEB packaging is
  selected.

This allows downstream projects to choose TGZ, DEB or RPM without modifying
libuca’s source tree.

Conan packaging and CI

• Update the package version to libuca 2.4.0.
• Use the SPDX-compatible LGPL-2.1-or-later license identifier.
• Update the GLib and libtiff dependencies.
• Export all source files required for an isolated package build.
• Add options for shared libraries, TIFF and optional proprietary camera SDKs.
• Reject invalid proprietary-SDK configurations early.
• Add a Conan lock file to make dependency resolution reproducible.
• Update the GitHub Actions checkout and Python setup actions.
• Install a bounded Conan 2 release explicitly.
• Build CI packages without proprietary camera SDKs.

Plugin discovery

Plugin discovery now:

• Matches only the filename rather than applying the expression to the complete
  path.

• Accepts plugin names containing letters, numbers, underscores and hyphens.

• Recognizes Linux shared libraries such as:

  libucamock.so
  libucanet.so
  libuca-camera_name.so
  libucacamera.so.2
  

• Recognizes the corresponding Windows DLL names.

• Ignores files that do not match the complete plugin naming convention.

• Releases the temporary camera-name list after counting network cameras.
  This prevents accidental matches and supports packaged/versioned shared
  libraries more reliably.
  TIFF output
  The uca-grab multi-page TIFF writer now:

• Sets image geometry before calculating the default strip size.

• Sets the photometric interpretation explicitly.

• Restores per-directory fields for every page because
  TIFFWriteDirectory() resets them.

• Calculates a valid strip size independently for each image directory.
  Compatibility notes

• The minimum CMake version is now 3.16.

• The minimum GLib version is now 2.56.

• The minimum libtiff version, when enabled, is now 4.3.

• The deprecated GTK 2 GUI is disabled by default and must be requested
  explicitly.

• The core libuca camera API and ABI are not intentionally changed by this pull
  request.
  Dependencies
  This is the first branch in the proposed feature series and has no dependency
  on the trigger, metadata, PCO.edge, uca-net or Concert changes.
  It is intended to serve as the build foundation for later, independent pull
  requests:

• Generic trigger and frame-metadata API

• PCO.edge CLHS camera plugin

• Ximea camera plugin
  Testing
  The resulting build configuration has been used successfully as the foundation
  for the PCO.edge plugin build.
  The following configurations should be covered by CI or reviewer testing:

• CMake core build without GUI

• CMake build with TIFF enabled

• CMake build with TIFF disabled

• Meson core build without GUI

• Meson build with TIFF enabled and disabled

• Conan 2 package creation without proprietary SDKs

• Existing libuca mock and ring-buffer tests

• Multi-page TIFF creation with uca-grab
  No camera hardware is required to review or test this pull request.

[tfarago]

Don't review yet, testing something

[NikolayZagainov]

This is testing pull request for PCO.EDGE, more will follow in the future

[NikolayZagainov]

This allows building libuca and its command-line tools without TIFF support—for example, for acquisition where images are transferred or processed directly instead of saved as TIFF. This is a general build fix discovered during the work, not a PCO requirement. It can be reviewed and merged separately—or left out of the initial PCO contribution.

[NikolayZagainov]

The rational behind these changes:

If we left the code unchanged, the camera could acquire correct images, but uca-grab could save them in a TIFF file that some programs read incorrectly or reject.

1. Calculating strip size before setting image dimensions.
   TIFF stores an image in blocks called strips. Choosing their size requires knowing how many bytes one image row occupies. At that point, the old code hadn’t supplied the width or pixel format. Depending on libtiff’s behavior, this could produce warnings or an unsuitable strip size. It does not necessarily corrupt pixels, but relies on fallback behavior.
2. Setting the page-type tag only for the first image.
   Finishing a TIFF page clears its settings. Consequently, subsequent images weren’t explicitly marked as pages of a multi-page document. Many readers still find them through TIFF’s directory chain, so this does not mean later frames disappear. However, the file is inconsistently described, and software relying on that tag may handle later pages differently.
3. Not declaring how grayscale values should be displayed.
   The missing tag tells the reader that zero means black and larger values mean brighter pixels. Without it, readers may assume a default, display the image incorrectly, warn about the missing information, or reject it. Adding PHOTOMETRIC_MINISBLACK makes the interpretation explicit.

I asked to find failure scenarious:

So it seems the firs one is serious. And the 2 and 3rd issues which may arise in other programs or apps during reading.

[matze]

My two cents: is it even worth keeping the GUI? I know most distros keep GTK 2 around forever but … I don't know if anyone other than me back then used it after integration with Concert became a thing.

[NikolayZagainov]

My two cents: is it even worth keeping the GUI? I know most distros keep GTK 2 around forever but … I don't know if anyone other than me back then used it after integration with Concert became a thing.

I have never saw anyone used it, so I also don't know why it is needed. But now it would be optional, so it does not matter much.

[tfarago]

@codex review