1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Proposed MBF: CMake 4.0 compatibility (1/2)

    From Timo =?utf-8?Q?R=C3=B6hling?=@21:1/5 to All on Wed Apr 23 21:50:01 2025
    --tjczcn4rta65juci
    Content-Type: text/plain; charset=utf-8; format=flowed
    Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable

    Hi,

    CMake has deprecated backwards compatibility for versions older than 3.5
    since July 2023, and the CMake 4.0 release finally drops support,
    causing all packages still relying (or declaring to rely) on older
    behavior to FTBFS.

    Trixie will ship with CMake 3.31, so this issue is only relevant for the
    Forky release cycle. However, I plan to file forky tagged bugs early, so
    that maintainers are aware and can forward the bug to upstream as
    needed.

    I have rebuilt the ~3000 packages which build-depend on CMake with
    debusine (thanks to Freexian for this helpful service and Stefano Rivera
    for his debusine-rebuilds tool) and discovered 936 affected packages;
    the dd-list is attached.

    If you want to fix your package, there are two options:

    1) Add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to dh_auto_configure, which
    will override any CMakeLists.txt settings. This is the minimally
    invasive procedure, no patching required. See also [1].

    2) Patch CMakeLists.txt and use the "..." range syntax to add a
    supported maximum version, e.g., cmake_minimum_required(VERSION
    3.2...3.31). This is the recommended way to submit bugfixes to upstream.

    In both cases, you should verify that CMake still behaves how the
    package expects it. If your package builds reproducibly, you can easily
    check that the binary packages remain unchanged. Alternatively, you can
    look for policy warnings in the current build logs, which will point you towards potential problems.


    Cheers
    Timo

    [1] https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_VERSION_MINIMUM.html


    --
    ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
    ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
    ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
    ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

    --tjczcn4rta65juci
    Content-Type: text/plain; charset=utf-8
    Content-Disposition: attachment; filename="cmake-4.0-dd-list.txt" Content-Transfer-Encoding: quoted-printable

    A. Maitland Bottoms <[email protected]>
    airspyhf (U)
    airspyone-host
    codec2
    gqrx-sdr
    hackrf
    inspectrum (U)
    libad9361-iio
    libm2k (U)
    libosmosdr
    libsigmf
    soapyuhd (U)
    uhd

    Aaron Boxer <[email protected]>
    libgrokj2k

    Adam Borowski <kilobyt
  • From Andreas Henriksson@21:1/5 to All on Thu Apr 24 09:50:01 2025
    Hello Timo,

    On Wed, Apr 23, 2025 at 09:49:07PM +0200, Timo R�hling wrote:
    Hi,

    CMake has deprecated backwards compatibility for versions older than 3.5 since July 2023, and the CMake 4.0 release finally drops support,
    [...]
    Andreas Henriksson <[email protected]>
    mfgtools (U)
    [...]

    Already fixed in upstream git and should be part of next upstream release: https://github.com/nxp-imx/mfgtools/commit/311ee9b3cca0275fbb5eb5228c56edbb518afd67

    FWIW My general feedback is that people will be distracted by a MBF
    right before a freeze (and will often miss forky tags and notices).
    Also if you wait just 'til after the freeze (start of forky) then likely
    a bunch of upstream will already have caught up and some people (like
    myself hopefully) will likely already have uploaded the latest upstream
    release and thus your MBF will be a lot fewer.
    But I also understand that you want to give the long tail as much
    heads up as possible. Maintainers can if bugs are filed set forwarded
    and fixed-upstream tag which can help if you want to work on patches
    for the remaining ones and upstream them. It's a judgement call and I
    guess as I see it, it depends alot on how much effort you intend to
    invest into the bugs after they have been filed...

    Regards,
    Andreas Henriksson

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Jeremy_B=C3=ADcha?=@21:1/5 to [email protected] on Tue Jun 3 14:20:02 2025
    On Wed, Apr 23, 2025 at 3:49 PM Timo Röhling <[email protected]> wrote:
    I have rebuilt the ~3000 packages which build-depend on CMake with
    debusine (thanks to Freexian for this helpful service and Stefano Rivera
    for his debusine-rebuilds tool) and discovered 936 affected packages;
    the dd-list is attached.

    If you want to fix your package, there are two options:

    1) Add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to dh_auto_configure, which
    will override any CMakeLists.txt settings. This is the minimally
    invasive procedure, no patching required. See also [1].
    …
    [1] https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_VERSION_MINIMUM.html

    Could we have debhelper do this by default for buildsystem=cmake (and cmake+ninja)?

    It feels like it would be so much nicer to update 1 package instead of
    more than 900.

    Thank you,
    Jeremy Bícha

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)