Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: curl test bundles and "unity" builds
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Matt Jolly via curl-distros <curl-distros_at_lists.haxx.se>
Date: Fri, 11 Apr 2025 17:02:40 +1000
Hi Viktor,
I ran some quick tests last night, no noticeable difference in build / test times with any combination of the options enabled (autotools).
This matches expectations; we're not dealing with the sort of code where I'd expect to see a realistic benefit from unity builds. Interested to see what others come up with but Gentoo packaging will continue to omit these options for the foreseeable future.
Cheers,
Matt
On 11 April 2025 4:38:50 am AEST, Viktor Szakats via curl-distros <curl-distros_at_lists.haxx.se> wrote:
>Hey Everyone,
>
>Thanks for today's call to all who joined!
>
>Here are the options I mentioned, which have a fair chance
>to make the build process faster:
>
>- To enable test bundles:
>configure: --enable-test-bundles
>cmake: -DCURL_TEST_BUNDLES=ON
>
>This will reduce the number of build steps for the test targets
>by quite a bit.
>
>- To enable unity builds:
>configure: --enable-unity
>cmake: -DCMAKE_UNITY_BUILD=ON
>
>This reduces build steps for libcurl, curl tool, and internal
>libs for tests. With cmake, it reduces steps further for tests too.
>
>For one shot builds unity is fine without reservations in
>most cases we saw so far.
>
>(For published binaries unity is likely fine for the curl tool and libcurl
>shared lib. For static libcurl, there is one caveat, which can be offset with
>`CFLAGS` `-ffunction-sections -fdata-sections`. These in turns increase
>lib size. Definitely something to test and compare, before enabling there .)
>
>Let me know if this worked, or there was any issue.
>
>Cheers,
>Viktor
>https://mastodon.social/_at_vsz
>https://github.com/vszakats
>--
>Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-distros
>Etiquette: https://curl.se/mail/etiquette.html
Matt
Date: Fri, 11 Apr 2025 17:02:40 +1000
Hi Viktor,
I ran some quick tests last night, no noticeable difference in build / test times with any combination of the options enabled (autotools).
This matches expectations; we're not dealing with the sort of code where I'd expect to see a realistic benefit from unity builds. Interested to see what others come up with but Gentoo packaging will continue to omit these options for the foreseeable future.
Cheers,
Matt
On 11 April 2025 4:38:50 am AEST, Viktor Szakats via curl-distros <curl-distros_at_lists.haxx.se> wrote:
>Hey Everyone,
>
>Thanks for today's call to all who joined!
>
>Here are the options I mentioned, which have a fair chance
>to make the build process faster:
>
>- To enable test bundles:
>configure: --enable-test-bundles
>cmake: -DCURL_TEST_BUNDLES=ON
>
>This will reduce the number of build steps for the test targets
>by quite a bit.
>
>- To enable unity builds:
>configure: --enable-unity
>cmake: -DCMAKE_UNITY_BUILD=ON
>
>This reduces build steps for libcurl, curl tool, and internal
>libs for tests. With cmake, it reduces steps further for tests too.
>
>For one shot builds unity is fine without reservations in
>most cases we saw so far.
>
>(For published binaries unity is likely fine for the curl tool and libcurl
>shared lib. For static libcurl, there is one caveat, which can be offset with
>`CFLAGS` `-ffunction-sections -fdata-sections`. These in turns increase
>lib size. Definitely something to test and compare, before enabling there .)
>
>Let me know if this worked, or there was any issue.
>
>Cheers,
>Viktor
>https://mastodon.social/_at_vsz
>https://github.com/vszakats
>--
>Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-distros
>Etiquette: https://curl.se/mail/etiquette.html
Matt
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-distros Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-04-11