Temp/reserve imap connecteon for operation - #100
Draft
dbezverkhnii wants to merge 20 commits into
Draft
Conversation
Idle timer stands down while a connection is reserved and is re-armed by releaseConnection; releaseConnection is idempotent and owner-checked; selection no longer stamps the affinity hint on reserved connections; threading contract documented; test endpoint descriptor lifecycle fixed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bridges the existing IMAPAsyncConnection::disconnectOperation() to C and Swift so a lease holder can tear its socket down before commands whose freshness matters: the next command logs in from scratch and sees the server's current mailbox view. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The installed header set was self-inconsistent: CIMAPAsyncSession.h, CIMAPBaseOperation.h and CCore.h include CIMAPAsyncConnection.h, but the CMake install list did not carry it. Also rights the leaked-lease wording in the Swift docs: the pool degrades to sharing, it does not shrink. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Swift-only: exposes the underlying pool connection's pointer as an opaque identity, unique and constant for the owning session's lifetime, so the client can key per-connection bookkeeping (view-freshness generations) across separate acquisitions of the same connection. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The mailcore2-all-<N>.zip archives for the Windows build are stored as release assets of this repository instead of the S3 bucket; upload and verification instructions now go through gh release. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Build-Helpers.ps1 provides minimal stand-ins for RDBuildCMake/RDBuildMSVC/ RDDependency and is dot-sourced only when those modules are absent, so a plain clone of the public repository builds with just the Swift toolchain and VS Build Tools. Dependencies are cloned over https instead of ssh, and one optional -PrebuiltDependenciesArchive supplies ICU, libxml2, openssl, sasl and zlib, replacing the S3 downloads and the manual C:\Library layout. Also installs the ICU and Swift runtime DLLs the artifact needs, fixes the tidy include/lib paths, and adds MCIMAPAsyncConnection.h to the C++ public headers - the C++ half of the header-install fix in 00e17d8. Authored on Windows by the build agent; carried over verbatim except for comments and the header-list fix. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…n COR-180 The archive is now named after the C/C++ sources it was built from (mailcore2-all-<digest>.zip), so there is no version to bump and no way to silently consume a stale binary: sources that were never built have no archive, and the spark-core build stops with a message naming the missing one. Since there is no Windows CI, that build is where the omission surfaces. The digest covers src minus src/swift, CMakeLists.txt and the new windows-build-pins.json (exact dependency revisions and toolchain versions), and is computed from git's tree entries, which makes it identical across platforms regardless of core.autocrlf. Build scripts are deliberately outside it: editing them must not invalidate good binaries. Publish-Mailcore2Prebuilt.ps1 does the whole job in one call - digest, skip if already published, toolchain check, build, stamp, package, verify, upload - and nothing needs to be committed afterwards. Downloads need no credentials now that the repository is public; the S3 path survives behind -LegacyS3Version for tags published before this change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…-180
Everything Windows now lives in one directory at the root, and the parts of
the flow that were prose are scripts.
Structure:
build-windows-5.10/ -> windows/
windows-build-pins.json -> windows/pins.json
build-windows/ -> windows/legacy-vs2019/ (superseded VS2019 scripts,
marked as such; they still expect the retired S3 bucket)
The digest scheme claimed more than it delivered. pins.json named a toolchain
and dependency revisions and fed them into the digest, but nothing made the
build actually use them, so two machines could publish different binaries
under the same name. Now every pinned value is binding:
- Initialize-Toolchain puts the pinned Swift and MSVC on PATH instead of the
first one it finds, and Invoke-VsDevCmd reads -vcvars_ver from the pins
rather than hardcoding 14.39.
- Initialize-Dependencies re-points an existing checkout at the pinned
revision and cleans it, instead of trusting any directory that has a .git.
- Publish verifies the install tree's recorded revisions against the pins
after the build, and deletes previous build output before it.
- ICU and libxml2 versions moved into the pins; their DLLs ship in the
archive, and they were duplicated across two scripts.
The S3 path is gone: Build-Mailcore2 fetches the public dependency archive on
demand, so -BuildMailcore2 no longer needs SPARK_PREBUILT_KEY - which the docs
already claimed. Tags published under the old scheme are unaffected, they run
their own copy of Get-Mailcore2.ps1.
New scripts:
- Setup-Machine.ps1 checks the machine against the pins and prints (or with
-Install runs) what is missing.
- New-DependenciesArchive.ps1 rebuilds the binary build inputs, which until
now was a paragraph in the README.
Also: -Force to re-publish a rebuilt archive under the same digest (documented
before, unsupported), archive verification no longer keys on headers this
branch happens to have added, and AGENTS.md/README.md are rewritten around the
two commands that matter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
macOS, iOS and Android have pull-request checks; Windows had none, so a forgotten upload only surfaced in the spark-core build. This asks the one question that matters - do these sources have a published archive? - and says so on the pull request page. It builds nothing. The digest is a hash of git tree entries, so it is the same on every platform and a Linux runner answers in seconds, running the very function the consumer runs rather than a reimplementation of it. It checks the merge result, because that is what lands on the base branch and gets tagged. When the base has moved since publishing, the branch head has an archive and the merge result does not; the check recognises that case and says to rebase instead of leaving the red unexplained. Get-MailcoreSourceDigest takes an optional -Ref for this, and the release asset lookup moved from the publish script into Common.ps1 so both use one copy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… COR-180 - README said the flow was "verified on a clean Windows machine". That was true of the flow before this rewrite, not of this one, which nobody has run end to end yet. Removed rather than softened. - Setup-Machine.ps1 is described as checking every prerequisite, so it now also checks PowerShell 7 and refuses to run anywhere but Windows, pointing at Check-PrebuiltPublished.ps1 for the question that needs no Windows. - Said in the README that the pull-request check is advisory until it is added to the branch protection rules, and that doing so before the first archive exists makes every C/C++ pull request red for no use. - Said in the History section that the directory move breaks callers outside this repository, naming the one that exists. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Checked Assert-MailcoreDependenciesLayout against the real mailcore2-windows-deps-1.zip and two of its required paths were wrong, so it would have rejected the one archive that exists: - libxml2 headers stay at usr/include/libxml2/libxml, where libxml2's own install step puts them. CMakeLists.txt:188 appends /libxml2 to LIBXML_INCLUDE_DIR on Windows, so nothing needs relaying - I had assumed the opposite and had New-DependenciesArchive.ps1 flatten it. - The sasl import library is sasl2.lib, not libsasl.lib. The published archive now passes the assertion, and the generator reproduces the layout it actually has. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…-180 Publish-Mailcore2Prebuilt.ps1 created the windows-prebuilt release when it was missing and could upload the dependency archive. Both are one-time manual acts and do not belong in a script that runs on every publish: a release recreated silently would hide that every archive previously on it had gone with it. - Removed the gh release create path and the -PublishDependenciesArchive parameter. Uploading is now the whole of Publish-ReleaseAsset. - A missing release fails during preflight with the two steps to set it up, so it is not discovered after a fifteen minute build. - The pull-request check tells "no release yet" apart from "no archive for these sources": the first is setup nobody has done, the second is a build nobody has published. - New-DependenciesArchive.ps1 no longer offers to publish what it built; it says to attach it and, if renamed, to update pins.json. - AGENTS.md tells the agent to report a missing release rather than create one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The release is permanent and nobody is going to delete it, so the manual setup does not need a section arguing for itself - just the tag, the kind of release and the archive to attach. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This branch is meant to change three things - where the binary lives, how it is pinned (by content digest instead of a version), and the instructions for building and uploading it. I had gone further and changed how the build works, which is not what it is for. Reverted to the 3ded97b versions, byte for byte apart from the relocation: - Build-Helpers.ps1: toolchain and dependency handling back as it was. No vswhere lookup, no MAILCORE_VS_ROOT / MAILCORE_SWIFT_ROOT, no reading -vcvars_ver from the pins, no re-pointing an existing dependency checkout, no cmake/ninja fallback. - Build-Mailcore2.ps1: the S3 path, the C:\Library layout, the hardcoded ICU and libxml2 versions and the original SDKROOT handling are all back. Only the dot-source and the four windows/vs paths differ. - Build-SwiftMailcore.ps1: identical to yours. - pins.json: identical to yours. The ICU/libxml2 versions I had added were read by nothing after the revert, and the comment claiming the toolchain is enforced was no longer true. - Deleted Setup-Machine.ps1, which installed Visual Studio through winget over whatever was already configured, and New-DependenciesArchive.ps1, which rebuilt the build inputs. Requirements and how the dependency archive was assembled are prose in the README again. Line endings were also collateral: several files had lost CRLF and are restored. What stays is the digest naming, Get-Mailcore2 downloading by it, Publish-Mailcore2Prebuilt adding to a release created by hand, the pull-request check, and the docs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mailcore2-all- was inherited from the S3 bucket, where mailcore2- was the distinguishing part among several projects' artifacts. On a windows-prebuilt release the platform is the part that was missing, and it sat next to mailcore2-windows-deps-1.zip, which did say it. Both now share the mailcore2-windows- prefix. The name is derived from the digest but is not part of it, so this does not change any digest. The directory inside the archive stays mailcore2-all: it is never seen outside the two scripts that agree on it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Check-PrebuiltPublished.ps1 still told people to run Setup-Machine.ps1, in the log and in the pull-request summary - the two places most likely to be read, and the ones I had not swept. Publish-Mailcore2Prebuilt.ps1 also still pointed at -PublishDependenciesArchive, a parameter that no longer exists; the dependency archive is attached to the release by hand. Checked the whole repository this time rather than the files I happened to touch, and verified that every command each script invokes resolves to something that exists - the only exceptions being Initialize-SDK and Invoke-BuildModuleTarget, which the Swift build takes from the RD modules by design. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"Move the Windows files into windows/" meant the 5.10 build scripts. I also pulled build-windows/ - the superseded VS2019 build - in under windows/legacy-vs2019/, which it did not need: it was already a self-contained directory in a sensible place, and nothing in this branch touches it. Back at the root, byte for byte, including its README - the "superseded" note I had added went with it. .gitignore paths and the README table follow. The only relocation left in the branch is the one that was asked for: build-windows-5.10/ -> windows/. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Everything is back where it was. build-windows-5.10/ keeps its name, the scripts and project files inside it were never relocated, and the pins are windows-build-pins.json at the root again. Build-Helpers.ps1, Build-Mailcore2.ps1, Build-SwiftMailcore.ps1, both .bat files, build_headers.*, bin/, mailcore2/, vs/ and windows-build-pins.json are now byte-identical to 3ded97b. Not one file in the branch is relocated any more. What the branch actually changes is what it set out to change: the archive is keyed by a digest of the sources instead of a version number, it lives in the GitHub release instead of S3, a pull-request check says when one is missing, and AGENTS.md and README.md describe building and uploading it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
No description provided.