vcpkg Nisan 2026: Kilitler, Hız ve Küçük Ama Kritik Dokunuşlar
vcpkg tarafında Nisan 2026 güncellemesi ilk bakışta “birkaç teknik düzeltme” gibi dürüyor. Ama işin içine biraz girince tablo değişiyor. En çok da paralel build’lerde kilitleme mantığının toparlanması, depend-info komutunun manifest modunda çalışması. PE bağımlılık analizinin artık çapraz platform hâle gelmesi, günlük paket yönetimiyle uğraşan ekipler için bayağı işe yarayan şeyler.
Açık konuşayım, ben bu tip release notlarını sadece “ne geldi?” diye okumuyorum. Asıl soru şu oluyor: büyük bir kurumsal repoda mı çalışıyorsunuz, yoksa birkaç geliştiricili küçük bir ekipte mi? Çünkü aynı özellik bazen biri için hayat kurtarıyor, öbürü için pek görünmez kalıyor. vcpkg’nın bu ayki paketi de tam öyle.
İşte tam da bu noktada devreye giriyor.
Geçen sene Kasım ayında bir müşteride — İstanbul’daki finans ekibiydi — MSBuild entegrasyonlu derleme sırasında iki farklı ajan aynı anda dependency çekmeye kalkınca saçma sapan kilitlenmeler yaşamıştık. O günlerde tek root üzerinden çalışan yapı bize ufak ama sınır bozucu gecikmeler çıkarıyordu. Bu yeni locking yaklaşımını okuyunca direkt o vaka aklıma geldi; çünkü problem kağıt üstünde küçük dürüyor (bu beni çok şaşırttı). Pratikte bütün pipeline’ı yavaşlatabiliyor.
Asıl mesele: vcpkg neden hâlâ önemli?
Bakın, vcpkg’nın güzel tarafı şu: C++ dünyasında paket yönetimini “herkes kendi yöntemini uydursun” karmaşasından çıkarıp daha düzenli hâle getiriyor. Tabiî tamamen steril bir dünya sunmuyor; orası ayrı. Bazı portlarda build süresi uzuyor, bazı triplet kombinasyonlarında sürpriz hata çıkıyor… ama yine de özellikle Microsoft ekosisteminde çalışan takımlar için fena değil, hatta bayağı kurtarıcı.
Nisan 2026 sürümünde toplam port sayısı 2.807’ye çıkmış durumda (en azından benim deneyimim böyle). 35 yeni port eklenmiş, 370 port güncellenmiş. Bu rakamları görünce insanın aklına “iyi de ben bunların hepsini kullanmıyorum ki” geliyor, haklısınız. Fakat kurumsal tarafta olay tek bir kütüphane değil; zincirin tamamı. Bir bağımlılık güncellendiğinde onunla ilişkili diğer parçaların da bozulmadan kalması gerekiyor.
Vallahi, Bence burada en kritik nokta topluluk ölçeği. 103 katkıcıdan bahsediyoruz; yanı iş tek bir ürün takımının kapalı döngüsü değil, açık kaynak ritmiyle ilerliyor (kendi tecrübem). Logosoft’ta geçtiğimiz yıl Ankara’daki bir üretim müşterisinde buna benzer bir model kullandığımızda şunu gördük: topluluk katkısı arttıkça yenilik hızı artıyor. Test disiplininiz zayıfsa küçük kırılmalar da beraber geliyor.
Kilit mekanizması neden göze batıyor?
Yeni release’in en somut parçası bence lock dosyasının VCPKG_ROOT altından alınıp installed dizinine taşınması. Kulağa sıradan geliyor olabilir ama multi-instance senaryolarda çok şey değiştiriyor. Aynı root’u paylaşan iki farklı vcpkg kurulumu varsa artık birbirinin ayağına basmadan farklı hedeflere yük yapabiliyor (en azından benim deneyimim böyle)
Benzer bir sorunu 2019’da kendi lab ortamımda yaşamıştım; o zamanlar eski tip paylaşılmış build klasörleri yüzünden “neden bu makine sürekli bekliyor?” diye kafa patlatıyorduk. Sonradan anladık ki sorun çoğu zaman derleyicide değilmiş, erişim sırasındaymış. Yanı dar boğaz CPU değil… kilit meselesiymiş.
Kurumsal yapılarda hız çoğu zaman ham performansla gelmiyor; doğru kilitleme stratejisi ve temiz ayrıştırılmış çalışma dizinleri daha fazla fark yaratıyor.
Paralel build’lerde ufak detaylar büyük fark yaratıyor
buildtrees ve packages dizinlerine eklenen yeni lock yaklaşımı özellikle paralel derlemelerde güvenilirliği artırıyor deniyor ve evet, bunun sahadaki karşılığı var. MSBuild entegrasyonu kullanan ekiplerde aynı anda birkaç çözümün koştuğunu düşünün; biri ortak cache’e yazarken diğeri okuma yaparsa arada tuhaf yarış durumları çıkabiliyor.
Çok konuştum, örnekle göstereyim.
Bu konuda ilginç olan şey şu: geliştirme makinelerinde çoğu kişi bunu fark etmiyor bile çünkü tek thread gibi davranan lokal işler gayet akıcı gidiyor. Ama CI/CD’de yük bindirince gerçek ortaya çıkıyor. İşte orada bu tarz iyileştirmeler sessiz kahraman oluyor — manşete çıkmıyor. Sabah build raporunuz yeşilse sebebi biraz da bu tür dokunuşlar (eh, fena değil)
Bakın, Küçük startup ekiplerinde ne yapmak lazım? Eğer beş-altı geliştiriciyseniz genelde merkezî bir vcpkg cache’i ile idare edebilirsiniz ama klasörlerin çakışmamasına dikkat edin (özellikle self-hosted runner varsa). Enterprise seviyede işe ben net şekilde izole edilmiş çalışma alanlarını öneririm; her pipeline’ın kendi installed yoluna yazması uzun vadede daha az baş ağrıtır.
| Senaryo | Öneri | Neden |
|---|---|---|
| Küçük ekip / tek repo | Sade kurulum + kontrollü cache | Daha az operasyon yükü |
| Büyük kurum / çoklu pipeline | Ayrı installed dizinleri + sıkı lock düzeni | Çakışma riskini düşürür |
| Cross-platform hedefler | Dizin izolasyonu + triplet bazlı test | Tahmin edilmez hataları azaltır |
Z-applocal ve depend-info neden benim ilgimi çekti?
z-applocal komutunun artık PE dependency analysis için çapraz platform çalışması bence iyi haberlerden biri öldü diyebilirim… fakat burada ufak bir hayal kırıklığı paylaşıyım: böyle özellikler duyunca herkes hemen “tamamdır” sanıyor ama saha gerçekleri daha inatçı oluyor. Windows dışındaki toolchain kombinasyonlarında yine de kontrol etmek gerekiyor.
dpend-info‘nun manifest mode desteği işe paket grafiğini anlamaya çalışan ekipler için ciddi rahatlık sağlıyor — pardon yanlış söyledim — ciddi rahatlık sağlıyor demek yeterli olur aslında! Geçen mart ayında İzmir’deki bir telekom müşterisinde bağımlılık ağacını elle takip etmek zorunda kalmıştık; yarım günümüz gitmişti resmen.
O yüzden böyle komutların manifest ile uyumlu olması bana göre lüks değil, temel ihtiyaç.
Neyi kolaylaştırıyor?
- Paket ağacını daha hızlı görüyorsunuz.
- Etkilenen bağımlılıkları tahmin etmek kolaylaşıyor. (bence en önemlisi)
- Migrasyon öncesi risk analizi biraz daha düzgün yapılıyor.
Açıkçası, Bunu Türkiye’deki şirketler açısından değerlendirirsek… Bizde hâlâ birçok — kendi adıma konuşayım — ekip dependency yönetimini “build geçsin yeter” seviyesinde tutuyor. Oysa kurumsalda asıl maliyet sonradan çıkıyor: gece yarısı bozulan pipeline, ertesi sabah kaybolan sprint saati ve ona eşlik eden moral düşüşü…
Sadece teknik değil, organizasyonel etkisi de var
Nisan sürümündeki terminoloji değişikliği de önemliydi bence:s upports expressions ? Hayır şöyle diyeyim — features içindeki supports ifadelerinin top-level ele alınması ve exclude kavramının skip olarak değiştirilmesi semantik açıdan işi sadeleştiriyor.
Yanı dil temizleniyor.
Ve bu küçümsenecek şey değil.
Bir terimin adı kötü olunca insanlar önü yanlış yorumluyor; sonra politika hatası teknik borca dönüşüyor.
Bu kadar basit.
Pratikte bunu özellikle Azure DevOps veya GitHub Actions tabanlı pipeline tasarlayan ekiplerde görüyoruz.
Bir işim karışıklığı bazen üç ayrı YAML revizyonu demek oluyor.
Sonra biri gelir “niye fail ediyor?” der…
Bu arada `–skip-failures` davranışındaki PR/CI modu farkının düzeltilmesi hoş olmuş.
Ben buna “görünmez tutarlılık işi” diyorum.
Kimse alkışlamaz ama herkes faydasını hisseder.
Az önce X dedim ama aslında Y daha doğru olabilir:
bu tür düzeltmeler doğrudan performans kazancı vermeyebilir,
ama operasyonel güven verir.
Bazen en değerli şey odur zaten.
# Basit mantık örneği
if (mode == "manifest") {
enable_dependency_graph();
use_skip_semantics();
} else {
keep_legacy_flow();
}
Beni düşündüren eksik taraf ne?
Aynısını dürüstçe söyleyeyim: vcpkg çok güçlü olsa da öğrenme eğrisi hâlâ hafif dik dürüyor.
Mesela de de C++ dünyasına yeni giren ekiplerde triplet mantığı ilk başta kafa karıştırabiliyor.
“Niye x64-windows-static ile x64-windows-static-md farklı davranıyor?” sorusu boşuna sorulmuyor;
hakikaten farklı davranıyorlar!
Ayrıca community triplets esnekliği güzel. Enterprise standardizasyonu seven kurumlarda bazen sorun çıkarabiliyor.
Bir bankacılık projesinde geçen yıl bunu yaşadık:
geliştiriciler özgürlük istiyordu,
platform ekibi işe tekrarlanabilirlik peşindeydi.
İkisini dengelemek mümkün…
ama orta yol bulunmazsa süreç uzuyor.
Burada benim tavsiyem şu:
küçük ekipseniz hızlı deneyin,
kurumsalsanız önceden karar verin,
hangi triplet’ler desteklenecek,
hangileri yasaklanacak,
hangi binary cache kullanılacak…
bunları yazılı hâle getirin.
Neyse uzatmayayım:
dokümantasyonsuz büyüyen vcpkg kullanımı genelde mutlu sonla bitmiyor.
Sahada ne yapardım?
- Tüm ana triplet’leri net listeye bağlardım.
- Paket güncellemelerini CI’de izole ederim.”
- Binary cache politikası koyarım.”
Sıkça Sorulan Sorular
Q&A bölümüne geçmeden önce kısa not:
Aşağıdaki sorular sahada en çok duyduğum tipik sorulara göre seçildi.
vcpkg Nisan 2026 sürümünde en önemli yenilik neydi?
Bence asıl fark yaratan şey kilit mekanizmalarının iyileştirilmesiydi. Paralel build yapan ortamlarda çakışmalar gerçekten can sıkıyordu, hani bu güncellemeyle o sorun epey azaldı. Açıkçası MSBuild kullanan kurumsal yapılarda etkisi çok daha net hissediliyor.
vcpkg depend-info artık ne işe yarıyor?
Manifest modunda proje bağımlılıklarını görmek artık çok daha kolay. Yanı etkilenen paketleri analiz ederken ciddi vakit kazanıyorsunuz. Aslında dependency ağacıyla boğuşmayı biraz olsun hafifletiyor, bu kadar.
Küçük takım mı yoksa büyük kurum mu daha çok faydalanır?
İkisi de faydalanıyor ama kullanım şekli farklılaşıyor. Küçük takımlar hız kazanıyor, büyük kurumlar işe çakışma ve bakım maliyetini düşürüyor. Tecrübeme göre enterprise tarafta etkisi çok daha görünür oluyor.
vcpkg öğrenmek zor mu?
Temelleri aslında oldukça kolay. Ama triplet ve manifest tarafına geldikçe iş büyümeye başlıyor, hani o kısımda biraz daha dikkat gerekiyor. Bir kere düzeni oturtursanız sonrası gerçekten rahatlıyor. Başlangıçta biraz sabır, o kadar.
Kaynaklar ve İleri Okuma
İlk olarak resmî vcpkg dokümantasyonuna göz atmanızı öneririm:
Ha bu arada changelog’u doğrudan incelemek isteyenler için araç deposu da burada:
Microsoft/vcpkg-tool GitHub Deposu
Bir de genel Microsoft C++ blog akışı üzerinden ilgili yayınları takip etmek iyi olur:
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.
2 comments