Builder curl-ares-solaris10-sparc Build #3134

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-curl-ares-solaris10-sparc' triggered this build

Steps and Logfiles:

1. git update ( 27 secs )
   1. stdio
2. Runtest './tests/testcurl.pl --nogitpull ...' ( 12 mins, 50 secs )
   1. stdio
   2. resultlog
3. Mail result 'cat resultlog ...' ( 0 secs )
   1. stdio

Build Properties:

Forced Build Properties:

Responsible Users:

1. Viktor Szakats

   commitohnoyoudont@vsz.me

Timing:

All Changes:

:

1. Change #250437

   Category	curl
   Changed by	Viktor Szakats <commitohnoyoudont@vsz.me>
   Changed at	Sat 29 Nov 2025 01:41:40
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	16f073ef49f94412000218c9f6ad04e3fd7e4d01

   Comments

   cmake: define dependencies as `IMPORTED` interface targets
   Rework the way curl's custom Find modules advertise their properties.
   
   Before this patch, Find modules returned detected dependency properties
   (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's
   main `CMakeLists.txt` copied their values into global lists, which it
   later applied to targets. This solution worked internally, but it was
   unsuited for the public, distributed `CURLConfig.cmake` and publishing
   curl's Find modules with it, due to polluting the namespace of consumer
   projects. It's also impractical to apply the many individual variables
   to every targets depending on libcurl.
   
   To allow using Find modules in consumer projects, this patch makes them
   define as imported interface targets, named `CURL::<dependency>`. Then
   store dependency information as target properties. It avoids namespace
   pollution and makes the dependency information apply automatically
   to all targets using `CURL::libcurl_static`.
   
   Find modules continue to return `*_FOUND` and `*_VERSION` variables.
   
   For dependencies detected via `pkg-config`, CMake 3.16+ is recommended.
   Older CMake versions have a varying degree of support for
   propagating/handling library directories. This may cause issues in envs
   where dependencies reside in non-system locations and detected via
   `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF`
   to fix these issues. Or upgrade to newer CMake, or link libcurl
   dynamically.
   
   Also:
   - re-enable `pkg-config` for old cmake `find_library()` integration
     tests.
   - make `curlinfo` build after these changes.
   - distribute local Find modules.
   - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`.
   - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in
     the consumer env.
   - add custom property to target property debug function.
   - the curl build process no longer modifies `CMAKE_C_FLAGS`.
     Follow-up to e86542038dda88dadf8959584e803895f979310c #17047
   
   Ref: #14930
   Ref: https://github.com/libssh2/libssh2/pull/1535
   Ref: https://github.com/libssh2/libssh2/pull/1571
   Ref: https://github.com/libssh2/libssh2/pull/1581
   Ref: https://github.com/libssh2/libssh2/pull/1623
   
   Closes #16973

   Changed files

   • CMake/FindBrotli.cmake
   • CMake/FindCares.cmake
   • CMake/FindGSS.cmake
   • CMake/FindGnuTLS.cmake
   • CMake/FindLDAP.cmake
   • CMake/FindLibbacktrace.cmake
   • CMake/FindLibgsasl.cmake
   • CMake/FindLibidn2.cmake
   • CMake/FindLibpsl.cmake
   • CMake/FindLibrtmp.cmake
   • CMake/FindLibssh.cmake
   • CMake/FindLibssh2.cmake
   • CMake/FindLibuv.cmake
   • CMake/FindMbedTLS.cmake
   • CMake/FindNGHTTP2.cmake
   • CMake/FindNGHTTP3.cmake
   • CMake/FindNGTCP2.cmake
   • CMake/FindNettle.cmake
   • CMake/FindQuiche.cmake
   • CMake/FindRustls.cmake
   • CMake/FindWolfSSL.cmake
   • CMake/FindZstd.cmake
   • CMake/Utilities.cmake
   • CMake/curl-config.cmake.in
   • CMakeLists.txt
   • lib/CMakeLists.txt
   • src/CMakeLists.txt
   • tests/cmake/test.sh