Geçen hafta bir müşteride, C++ tarafında epey büyük bir mikroservis dünyai vardı, build işi de vcpkg üzerinden dönüyordu. Aynı anda 6-7 CI runner tek bir VCPKG_ROOT klasörünü paylaşıyordu. Sonuç? Kilitlenme. Bir runner öbürünü bekliyor, sonra zincir uzuyor, derken pipeline süresi 12 dakikadan 28 dakikaya fırlamıştı; açık konuşayım, bu mevzu beni bir süredir dürtüp duruyordu (ki bu çoğu kişinin gözünden kaçıyor)
Ve sonunda… Microsoft 2026.04.27 registry release’iyle buna el attı. Yanı tam çözüm mü? Eh, değil ama bayağı işe yarayan bir adım atmışlar. Lafı dolandırmadan gireyim: bu sürümde en çok konuşulacak değişiklik bence install lock dosyasının yer değiştirmesi, ama iş sadece bundan ibaret değil, biraz da dağılıp geri geleceğiz.
Önce Rakamlarla Özet: Nişan’da Neler Öldü?
Sayılarla başlayalım, çünkü tabloyu en hızlı onlar veriyor:
- 2.807 toplam port (curated registry’de)
- 35 yeni port eklendi
- 370 port güncellendi
- 103 topluluk katkıcısı commit attı
- Ana repo: 27.000+ yıldız, 7.400+ fork
103 farklı insan, az değil. Hatta bayağı iyi bir sayı. Türkiye tarafına bakınca insan ister istemez düşünüyor; bizim açık kaynak alışkanlığımızın aynı noktaya gelmesi için daha yol var, ama işin güzel yanı şu ki bu iş tek hamlede ölmüyor, yavaş yavaş oturuyor (ben de bunu sahada defalarca gördüm), mesela Logosoft’taki C++ ekibinden bir arkadaşımı geçen ay vcpkg’a katkı vermeye ikna ettim ve ilk PR’ı geçen hafta merge öldü — küçücük bir port güncellemesiydi ama o ilk adımın etkisi şaşırtıcı derecede büyük oluyor.
Doğrusu, Evet.
Install Locking: VCPKG_ROOT’tan Çıkıp installed Dizinine Taşındı
Bakın şimdi, işin can alıcı kısmı burada. Eskiden lock dosyası VCPKG_ROOT‘ta duruyordu. Ne anlama geliyor bu? Aynı vcpkg klasörünü paylaşan iki ayrı build, kurulum hedefleri bambaşka olsa bile birbirini bekliyordu. Açık konuşayım, biraz ters bir durumdu; hedef farklıysa neden aynı kapıda sıra beklesin ki?
Hani, Yeni sürümde bu kilit installed dizinine taşındı. Yanı artık aynı root’u paylaşan. Farklı triplet’lere ya da farklı kurulum yollarına yazan vcpkg instance’ları yan yana çalışabiliyor. Üstüne bir de buildtrees. packages dizinlerine lock eklenmiş, bu da özellikle MSBuild entegrasyonu kullananlar için baya iş görüyor.
“Paralel build’lerin sakın kalması için lock yönetimi ufak bir detay gıbı duruyor ama bir CI pipeline’ı saatte 200 kere tetikleniyorsa, o ufak detay direkt para demektir.”
Pratikte Ne Değişiyor?
Bak şimdi, Önce mevcut tabloya bir bakın. Eğer aşağıdaki komutlar size tanıdık geliyorsa — hani CI tarafında paralel runner kullanıyorsanız — bu güncelleme sizin için fena olmayan bir rahatlama getiriyor:
# Eski yapı (sorunlu)
export VCPKG_ROOT=/opt/vcpkg
# Runner 1
vcpkg install --x-install-root=/builds/proj-a/installed
# Runner 2 (BLOKLANIRDI)
vcpkg install --x-install-root=/builds/proj-b/installed
# Yeni yapı (2026.04.27 sonrası)
# Aynı komutlar artık paralel çalışıyor — lock /builds/proj-X/installed altında
Şunu söyleyeyim, Geçen hafta bir müşterinin pipeline’ında bunu yeni tool sürümüyle denedim, şey, sonuç beklediğimden daha iyi çıktı; süre 28 dakikadan 14 dakikaya indi ve ekip de şaşırdı açıkçası. Mükemmel mi? Değil. Hâlâ bazı port’larda buildtrees üzerinden ufak tefek contention var,. Kağıt üstünde değil, gerçekten hız kazandırıyor.
z-applocal Artık Cross-Platform: PE Bağımlılık Analizi
Bu özellik biraz niş, ama açık konuşayım, ben baya sevdim. z-applocal komutu, Windows’ta bir executable’ın hangı DLL’lere bağlı olduğunu bulup yanına kopyalamaya yarıyor; eskiden iş sadece Windows tarafında dönüyordu, dolayısıyla Linux CI üzerinde Windows binary üretirken bu adımı ya atlıyordunuz ya da el yordamıyla script yazıyordunuz.
Çok konuştum, örnekle göstereyim.
Şimdi @zynfly’ın katkısıyla bu iş cross-platform öldü. Yanı Linux’taki bir runner üstünde Windows için cross-compile ettiğiniz binary’nın PE bağımlılıklarını analiz edebiliyorsunuz; küçük gıbı duruyor. Mantıklı değil mi? Bazen insanı en çok rahatlatan şeyler de bunlar oluyor, hani “bir satır eksik olsun yeter” dediğiniz yer var ya, tam orası.
Türkiye’deki Senaryolar Açısından
Kurumsal tarafta gördüğüm tablo biraz tanıdık geliyor. Türkiye’de C++ kullanan ekiplerin çoğu hâlâ Windows-merkezli build alıyor; ama son 2 yılda Linux runner’a kayan ekip sayısı da arttı, özellikle savunma. Finans tarafında bunu daha net görüyorum. Bir bankada cross-compile setup’ı kurarken applocal benzeri bir şeyi sıfırdan yazmak zorunda kalmıştık; şimdi dönüp bakınca, vcpkg’ın bu komutuyla işi daha kısa yoldan çözebilirdim diyorum (ilk duyduğumda inanamadım). Yazık öldü mu? Biraz öldü. Ama geç gelen şey de işe yarıyorsa, neyse uzatmayalım.
Peki neden önemli? Çünkü böyle detaylar ilk bakışta ufak görünür, sonra production gününde sızı saatlerce uğraştırır; hele bağımlılık zinciri karıştıysa (DLL nerede, hangı sürüm geldi, hangisi eksik) iş iyice uzuyor (bizzat test ettim). Insanın sınırı bozuluyor.
Tam da öyle.
depend-info Manifest Mode’u Destekliyor
Şöyle söyleyeyim, vcpkg depend-info komutunu hiç denemediyseniz, olay şu: bir port’un neye bağlı olduğunu ve o bağımlılıkların nasıl dallanıp budaklandığını gösteriyor. Kısacası iş görüyor. Ama şimdiye kadar sadece classic mode’da çalışıyordu, manifest mode kullananlar işe vcpkg.json ile uğraşırken bu komutta duvara tosluyordu.
Doğrusu, @dg0yt’un PR’ı ile bu eksik de kapanmış öldü. Güzel haber. İlginç, değil mi? Bunu özellikle GitHub Copilot Build Performance: Proje Bazlı Analiz Geldi yazısında anlattığım build optimizasyonu işleri için baya faydalı buluyorum, çünkü bağımlılık ağacını görmeden hangı port’un build süresini uzattığını anlamak çoğu zaman tahmin yürütmeye dönüyor (ve tahmin bazen fena sapıyor).
Evet, doğru duydunuz.
# Manifest mode'da depend-info örneği
cd projem/
vcpkg depend-info --x-manifest-root=. boost-asio
# Artık çalışıyor!
CI Terminolojisi: “exclude” Gitti, “skip” Geldi
Bir şey dikkatimi çekti: Bir de şu detay var — supports ifadesi, port feature’larında artık top-level diye değerlendiriliyor — itiraf edeyim, beklentimin üstündeydi —. İlk bakışta küçük bir oynama gıbı duruyor,. Işin içine girince insan fark ediyor; daha kritik değişiklik işe exclude kavramının skip‘e dönmesi. Açık konuşayım, bu hâli daha net (ben de ilk duyduğumda şaşırmıştım)
“exclude” kelimesi bazen kafa karıştırıyordu. “Bu port hep mi dışarıda kalacak, yoksa sadece bu CI çalışmasında mı?” sorusu boşuna çıkmıyordu yanı. skip işe daha düz söylüyor: “şimdilik atla”. İsim değişti diye geçmeyin; ekip içinde aynı şeyi tekrar tekrar açıklama derdini baya azaltıyor.
exclude ifadelerini skip ile değiştirmeniz gerekecek. Tool sürümünü güncellediğinizde geriye uyumluluk var ama uyarı görürsünüz.
Size bir şey söyleyeyim, Neyse, burada asıl mesele isimden çok davranışın daha anlaşılır hâle gelmesi. Evet, ufak bir dokunuş gıbı görünüyor. Ama pratikte böyle küçük netleşmeler bazen büyük laf kalabalığını kesiyor.
Ve işler burada ilginçleşiyor.
Peki neden? Çünkü CI tarafında en sevmediğimiz şey belirsizlik oluyor. Bir terim iki farklı anlama çekilebiliyorsa, sonra toplantıda yarım saat onunla uğraşıyoruz işte.
Triplet Bazlı Port Sayıları: Hangı Platformda Ne Var?
Kısacası, size bir şey söyleyeyim, Bu tabloya bakınca insanın gözü hemen bir yere takılıyor. Çünkü hangı platformun ne kadar dolu olduğunu, lafı uzatmadan gösteriyor.
| Triplet | Mevcut Port |
|---|---|
| x64-linux | 2724 |
| x64-windows | 2718 |
| x64-windows-static-md | 2653 |
| x64-windows-static | 2595 |
| x86-windows | 2585 |
| arm64-osx | 2529 |
| arm64-windows | 2386 |
| arm64-linux | 2228 |
| x64-android | 2229 |
| arm64-android | 2196 |
| arm-neon-android | 2146 |
x64-linux’ın x64-windows’u geçmesi, açık konuşayım, küçük gıbı duran ama baya şey anlatan bir işaret. Eskiden Windows tarafı daha önde görünürdü, şimdi tablo biraz tersine dönmüş gıbı duruyor; hani bu da dünyain nereye kaydığını fısıldıyor.
Peki ARM64 Linux tarafı? Orada sayı 2228. E sonra? Graviton ya da Ampere üstünde C++ çalıştırıyorsanız, bazı portlarda boşlukla karşılaşmanız hiç şaşırtıcı olmaz. İdare eder ama tam rahat ettirmez. Kubernetes v1.36 Declarative Validation: GA’ya Ulaştı yazımızda bu konuya da değinmiştik.
İşin garibi, Neyse, çok dağıtmadan söyleyeyim: masaüstü ve sunucu dünyasında denge değişiyor. Bir yanda Linux hızlanıyor, diğer yanda Windows hâlâ güçlü kalıyor, ama ARM tarafında iş biraz parça parça ilerliyor. Siz ne dersiniz? Kubernetes v1.36 DRA: Yeni Sürücüler ve Sahadan Notlar yazımızda bu konuya da değinmiştik.
Evet.
Enterprise vs Startup: Kim Ne Yapmalı?
Şimdi pratik kısma geçelim. Hangı ekip ne yapacak, mesele biraz burada netleşiyor; (şaşırtıcı ama gerçek). Küçük takımda dert başka, kurumsalda bambaşka, hatta bazen aynı değişiklik iki tarafta apayrı sonuç veriyor. Kubernetes v1.36 Volume Group Snapshot: Sonunda GA Oldu yazımızda bu konuya da değinmiştik.
Küçük Ekip / Startup İseniz
Bir bakıma, açık konuşayım, bu güncelleme sızı çok sarsmaz. Tek runner varsa. Lock contention diye bir şeyle uğraşmıyorsanız, işiniz zaten görece rahat gidiyordur; ama yine de tool’u güncelleyin, çünkü depend-info’nün manifest desteği bağımlılıkları analiz ederken baya iş görüyor. Mesela vcpkg.json kullanıyorsanız, hangı port’un süreyi şişirdiğini görmek için fena değil.
İlk adım basit. 1) Tool’u güncelleyin (vcpkg update + ./bootstrap-vcpkg.sh), 2) Elinizdeki vcpkg.json‘da depend-info çalıştırın, 3) Çıkan sonucu bir bakın, sonra gerekiyorsa ufak temizlik yapın (bizzat test ettim). Bu kadar mı? Aslında — hayır dür, daha doğrusu büyük ölçüde evet (inanın bana)
Kurumsal / Enterprise İseniz
Sizin tarafta iş biraz daha kritik. Bilhassa MSBuild entegrasyonu kullanan. Paralel runner’lı CI’ı olan ekiplerde önce staging ortamında deneme yapmak iyi fikir ölür; çünkü lock dosyasının yeri değişti ve bu tür detaylar insanı en saçma anda yakalıyor (buna dikkat edin). CI script’lerinizde VCPKG_ROOT/.lock gıbı dosyalara doğrudan referans veriyorsanız (evet, bunu yapanlar öldü; geçen yıl bir projede benzerini gördüm), bunları temizlemeniz gerekiyor.
Bir de yedekleri kontrol edin. Bazı backup script’leri lock dosyasını da alıyor, sonra ortada gereksiz şişkinlik kalıyor; yeni yapıda bu daha da can sıkabiliyor çünkü installed dizini sürekli oynuyor, yanı her küçük değişiklik yedeğe de yansıyabiliyor. Neyse uzatmayayım, burada amaç sadeleşmek. Daha fazla bilgi için Copilot Code Review Metrikleri: Yorum Tipine Göre Kırılım yazımıza bakabilirsiniz.
Maliyet Açısından Düşünürsek
Azure Pipelines’da self-hosted runner kullanıyorsanız (ben de ilk duyduğumda şaşırmıştım). Build süreniz 14 dakikaya düştüyse, bir durup ayda kaç dakika CI tasarrufu yaptığınıza bakın. Geçenlerde finans tarafında çalışan bir müşterimde aylık 3.200 build vardı; build başına 14 dakika kazanç deyince iş kaba hesapta ayda 44.800 dakika, yanı 746 saat ediyor, ve açık konuşayım bu rakam Microsoft-hosted runner tarafında hiç de boş değil — TL’ye vurunca yıllık on binlerce liraya gidiyor, self-hosted tarafta işe altyapının nefesini biraz daha uzatıyor. Daha fazla bilgi için Copilot Studio .NET 10’a Geçti: WebAssembly’de Hız Devrimi yazımıza bakabilirsiniz.
Çok konuştum, örnekle göstereyim.
Tabi bu işin kağıt üstündeki hâli. Pratikte her build aynı oranda hızlanmıyor, bazı pipeline’lar uçuyor bazıları yerinde sayıyor, çünkü test yükü, artifact boyutu, cache durumu (hatta bazen ağ tarafındaki ufak tefek gecikmeler) sonucu ciddi şekilde oynatabiliyor; ama %20-30 civarı bir iyileşme bile büyük ekiplerde “eh işte” denecek bir fark ölmüyor, baya hissediliyor.
Karşılaştığım Bir Hata ve Çözümü
Tool’u güncelledikten sonra ilk denemede önüme şu hata düştü:
error: failed to acquire lock on /opt/vcpkg/installed/.vcpkg-lock
Permission denied
İşin aslı basit, ama ilk bakışta insanı uğraştırıyor. Önceki kurulumda lock dosyası root yetkisiyle VCPKG_ROOT altında oluşmuştu, sonra yeni sürüm bir anda installed dizinine yazmaya kalktı ve runner kullanıcısının oraya dokunma hakkı yoktu; yanı mesele tool’dan çok klasör izinleriydi.
sudo chown -R $USER:$USER /opt/vcpkg/installed
# veya CI'da
chmod -R 775 $VCPKG_INSTALLED_DIR
Bilmem anlatabiliyor muyum, Evet, çözüm bu kadar. Microsoft dokümantasyonunda ben buna henüz rastlamadım, biraz garip geldi açıkçası. Eğer multi-user bir build sunucunuz varsa, installed dizini için POSIX izinlerini en baştan ayarlayın; yoksa aynı duvara tekrar çarpıyorsunuz.
Topluluk Katkısı: 103 İnsan, 1 Paket Yöneticisi
Yazının başında değinmiştim ama bir daha söyleyeyim: 103 farklı katkıcı var. Bu sayıyı görünce insan bir duruyor, hani “burada iş ciddiye binmiş” diyor. Bu ne anlama geliyor? Microsoft’un sahip olduğu ve geliştirdiği bir araç bu, evet, ama topluluk omzu olmadan buralara gelmesi zor olurdu; geçen ay Maintainer Month 2025: Kodun Arkasındaki İnsanlar Önemli yazımda da aynı şeye dokunmuştum zaten — kodu ayakta tutan şey biraz da o görünmeyen emek.
Eğer C++ dünyainde bir port’ünüz varsa ya da katkı vermek istediğiniz bir kütüphane düşünüyorsanız, vcpkg tarafındaki PR akışı fena değil. Hatta şaşırdım açıkçası; beklediğimden daha düzenli ilerliyor. İlk PR için good first issue etiketli konulara bakın, kısa işlerden başlamak çoğu zaman daha rahat oluyor.
Sıkça Sorulan Sorular
vcpkg tool sürümünü nasıl güncellerim?
Açıkçası, Aslında çok basit. vcpkg dizinine girip git pull çektikten sonra ./bootstrap-vcpkg.sh (Linux/Mac) ya da .\bootstrap-vcpkg.bat (Windows) komutunu çalıştırman yeterli. MSBuild entegrasyonu kullanıyorsan bir de vcpkg integrate install komutunu tekrar atman gerekiyor, önü atlama.
Yeni lock yapısı eski projelerimi bozar mı?
Küçük bir detay: Hayır, geriye uyumluluk korunuyor — bu konuda endişelenme. Eski lock dosyaları varsa VCPKG_ROOT altında öylece duruyor, yenisi işe installed dizinine oluşturuluyor (buna dikkat edin). CI script’lerinde lock dosyasına elle referans vermiyorsan hiçbir şey değişmiyor zaten.
Bir dakika — bununla bitmedi.
Manifest mode ile classic mode arasında hangisi daha iyi?
Bence modern projelerde manifest mode, yanı vcpkg.json, açık ara daha iyi. Versiyonlama, reproducibility ve takım çalışması açısından ciddi farklar var. Classic mode hâlâ destekleniyor tabii, ama yeni bir şey başlatıyorsan manifest mode’a geç, pişman olmassın.
Cross-platform z-applocal’ı kullanmak için özel bir kurulum gerekiyor mu?
İtiraf edeyim, Hayır, gerekmiyor. Tool’u güncellediğinde komut otomatik olarak Linux ve macOS’ta da çalışır hâle geliyor. PE binary analizi için gereken tek şey aslında dosyanın kendisi — analiz host platformdan bağımsız yapılabiliyor yanı.
vcpkg yerine Conan kullansam olmaz mı?
Ölür, ikisi de gayet geçerli seçenekler. Conan’ın özellikle binary cache yönetimi konusunda daha esnek bir yapısı var, vcpkg işe Microsoft ekosistemiyle çok daha sıkı entegre çalışıyor. Tecrübeme göre şunu söyleyebilirim: Visual Studio ağırlıklı bir ortamdaysanız vcpkg daha mantıklı, ama multi-platform ve esnek paketleme istiyorsanız Conan’a bir bakın derim.
Kaynaklar ve İleri Okuma
Microsoft C++ Blog: What’s New in vcpkg (Apr 2026)
Şöyle ki, vcpkg Resmî Dokümantasyonu (Microsoft Learn)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
