RFC: Add features to POCO to allow reducing build time #43337
+43
−9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: this isn't marked as a draft as I am hoping to get feedback on it, although I do not intend for it to be submitted as-is.
Background
We use POCO as part of a C++ plugin system, which involves building POCO into our main application/library as well as separate plugin libraries (see
Poco::ClassLoader
). I'm trying to reduce friction for new plugin authors, a large part of which is due to a slow first-compile experience which is dominated by time spent by vcpkg building POCO, especially on older/slower machines.POCO has good support for building a subset of the library, as seen in its
CMakeLists.txt
. A small subset of these options are supported by the vcpkg port today, mostly as a way to limit dependencies.Proposal
Create vcpkg features for the poco port which align with the rest of the
ENABLE_<FEATURE>
options supported by POCO'sCMakeLists.txt
, including in cases where no third-party vcpkg dependencies are required (e.g.ENABLE_MONGODB
). This would allow users to only build the relevant subset of POCO when first-build times are important.Set the default features of the poco port to be equivalent to the current functionality, to avoid breaking existing clients. Potentially remove the default features upon the next version bump, although this is not required.
I am happy to do the legwork here if the vcpkg leadership agrees with the direction, and have mocked up the changes for a few features in this PR.
History of sqlite3 feature
It seems that the vcpkg poco port has actually regressed in this area (see #42751), having recently removed a
sqlite3
feature resulting in thesqlite3
dependency being required andENABLE_DATA_SQLITE
being left in the defaultON
state. This is unfortunate, as in addition to the increased build time it also gets picked up as a dependency by open-source license and vulnerability management toolchains like ORT.Build performance impact
Removing even a few features can greatly reduce POCO's build times. I used Clang's
-ftime-trace
feature and ClangBuildAnalyzer to take some rough measurements of building the poco port locally.These numbers don't include time spent (or not) building other ports, i.e. the time saved by not building the sqlite3 port itself is not reported.
State of master as of 1/17/2025
With
activerecord
,cppparser
,pocodoc
,sqlite3
support disabledFrom the build logs I expect further savings are possible, but wanted to get an RFC up first.