fix(pdfx): gate DOWNLOAD_EXTRACT_TIMESTAMP on CMake < 3.24 (Windows build)

[Ahmedmmy97]

Summary

Fixes the Windows build failure reported in #601 (and the duplicate routed via flutter/flutter#186062) for users on CMake < 3.24. The plugin currently passes DOWNLOAD_EXTRACT_TIMESTAMP FALSE to download_project unconditionally, but that ExternalProject_Add keyword was only added in CMake 3.24. On older CMake — including 3.20 bundled with Visual Studio 2019 BuildTools — the keyword is unrecognised and cmake_parse_arguments absorbs it (and its FALSE value) as additional values of the most recent multi-value keyword, URL. The URL bucket becomes a 3-entry list, the validator in Modules/ExternalProject.cmake walks it, finds entries that don't match ^[a-z]+://, and bails with:

CMake Error at .../cmake-3.20/Modules/ExternalProject.cmake:2771 (message):
  At least one entry of URL is a path (invalid in a list)
Call Stack (most recent call first):
  .../cmake-3.20/Modules/ExternalProject.cmake:3681 (_ep_add_download_command)
  CMakeLists.txt:9 (ExternalProject_Add)

CMake Error at .../pdfx/windows/DownloadProject.cmake:171 (message):
  CMake step for pdfium failed: 1

The plugin declares cmake_minimum_required(VERSION 3.15) while using a 3.24+ keyword unconditionally — this PR closes that mismatch.

Fix

Gate the DOWNLOAD_EXTRACT_TIMESTAMP FALSE arguments on CMAKE_VERSION VERSION_LESS "3.24". On modern CMake the behaviour is unchanged. On CMake 3.20–3.23 the option is omitted and download_project succeeds (the only effect of omitting it is a CMake-3.24 deprecation warning about extracted-file timestamps, which is harmless for non-reproducible-build users).

set(_pdfx_extra_args)
if(NOT CMAKE_VERSION VERSION_LESS "3.24")
  list(APPEND _pdfx_extra_args DOWNLOAD_EXTRACT_TIMESTAMP FALSE)
endif()
download_project(
  PROJ pdfium
  URL ${PDFIUM_URL}
  ${_pdfx_extra_args}
)

Verification

Reproduced and verified in a Docker harness using ubuntu:24.04 + the official cmake-3.20.6 Linux binary, the unmodified windows/CMakeLists.txt and DownloadProject.cmake from main. The bug is purely CMake-argument-parsing — no Windows-specific behaviour is needed to reproduce it.

Case	Outcome
CMake 3.20.6 + current main	fails with the exact error chain (ExternalProject.cmake:2773 → 3683 → CMakeLists.txt:9)
CMake 3.20.6 + this PR	configures and downloads pdfium successfully
CMake 3.28.x + current main	already works; no regression with this PR

The line numbers in the user-reported stack (2771 / 3681) vs reproduction (2773 / 3683) differ by 2 because of patch-level differences between the VS2019-bundled CMake 3.20.x and the official 3.20.6 release; the call-graph and validator logic are identical.

Scope

• Touches only packages/pdfx/windows/CMakeLists.txt. No Dart, no other platforms.
• No cmake_minimum_required bump — keeps VS2019 BuildTools users supported.
• The unrelated download_project(PROJ\n pdfium ...) formatting was tightened to one keyword/value per line, matching the rest of the file.

Refs

• Refs pdfx plugin fails to build on Windows after updating to Visual Studio 2026 #601 (this is the VS2019 / CMake 3.20 root cause for that error chain — see caveat below)
• Refs flutter/flutter#186062 (closed there as third-party — same root cause, different reporter)

Deliberately not auto-closing #601 — see caveat.

Caveat on #601

The original #601 reporter is on Visual Studio 2026, which ships CMake ≥ 3.30. On that version DOWNLOAD_EXTRACT_TIMESTAMP is recognised, so this PR may not address the exact trigger they hit even though their error chain is identical. I haven't been able to reproduce the VS2026 variant. Happy to leave #601 open if the maintainer prefers and re-target this PR at a fresh "build fails on VS2019 / CMake 3.20" issue, or merge as-is and ask the #601 reporter to retest.