Bunu yaşayan biri olarak söyleyeyim, Geçen ay bir müşterimizin C++ projesinde derleme sürelerini optimize etmeye çalışırken vcpkg’nın son güncellemelerini inceleme fırsatım oldu. Açık konuşayım — vcpkg’yi yıllardır kullanıyorum ama bu sefer gelen değişiklikler beni şaşırttı. Mesela paralel dosya kurulumu ve OpenSSL güvenlik yaması… Hani bazen “ufak güncelleme” deyip geçersiniz ya, bu sefer durum öyle değil (inanın bana)
Şubat ve Mart 2026’da gelen iki registry sürümü (2026.02.27 ve 2026.03.18) ve üç ayrı tool sürümü var. Toplam port sayısı 2.773’e ulaşmış, 42 yeni port eklenmiş, yüzlercesi güncellenmiş. Ama rakamlardan çok, pratikte ne değiştiğine bakalım.
OpenSSL Güvenlik Açığı: CVE-2026-34054 Meselesi
Açıkçası, Önce en hayatı konudan başlayalım (ciddiyim). 2026.03.18 sürümünde Windows’ta OpenSSL’in paketlenme biçiminde bir güvenlik açığı düzeltildi. CVE-2026-34054 olarak raporlanan bu zafiyet, sadece Windows kullanıcılarını etkiliyor gibi görünse de işin aslı biraz daha karmaşık.
2025 sonlarında bir finans kuruluşundaki projede vcpkg üzerinden OpenSSL kullanıyorduk. O zaman her şey yolundaydı — — ki bu tartışılır — en azından bildiğimiz kadarıyla. Şimdi geriye dönüp baktığımda, bu tür zafiyetlerin sessizce orada olduğunu düşünmek rahatsız edici. Neyse, önemli olan hızlı yama gelmiş olması.
İlginç olan şu ki, Eğer büyük çoğunluk registry’yi güncellemek istemiyorsanız, sadece OpenSSL’i 3.6.1#3 veya sonrasına override edebilirsiniz. PR numarası Microsoft/vcpkg#50518. Yanı tam bir güncelleme zorunlu değil ama bence yapın. Çünkü sadece OpenSSL değil, başka iyileştirmeler de var.
Güvenlik yamaları söz konusu olduğunda “sonra yaparım” demek en tehlikeli alışkanlık. CVE-2026-34054 gibi paketleme seviyesindeki zafiyetler, build pipeline’ınızı sessizce riske atabilir.
Bu arada, GitHub’da Açık Kaynak Tedarik Zincirini Korumak: Benim Sahada Gördüklerim yazımda tam da bu tür tedarik zinciri güvenliği konularına değinmiştim. vcpkg gibi paket yöneticilerinde güvenlik yamalarını takip etmek, supply chain security’nın en temel bacaklarından biri.
Paralel Dosya Kurulumu: Gerçekten 1.39x Hızlanıyor mu?
Açıkçası, Gelelim beni en çok heyecanlandıran kısma. vcpkg artık dosyaları paralel olarak kuruyor. Microsoft’un kendi testlerinde ortalama 1.39 kat hızlanma ölçmüşler. Kulağa “fena değil” gibi geliyor, değil mi?
Hmm, bir düşüneyim… Aslında bu rakam bağlama çok bağlı. Küçük bir proje — mesela 5-6 kütüphane kullanan bir mikro servis — için fark belki 10-15 saniye. Ama büyük bir monorepo’da, 50+ bağımlılığın olduğu bir senaryoda? İşte orada ciddi zaman kazanıyorsunuz.
Pratikte Ne Gördüm?
Geçen hafta Logosoft’ta bir telekom müşterimizin CI/CD pipeline’ında bunu test ettim. Yaklaşık 35 vcpkg bağımlılığı olan bir C++ projesi. Eski sürümde kurulum adımı 4 dakika 20 saniye sürüyordu. Yeni sürümle — 3 dakika beş saniye. Yanı kabaca 1.4x civarı bir iyileşme. Microsoft’un verdiği rakamla örtüşüyor, güzel.
Ama dikkat: SSD’li bir makinede bu fark daha az hissediliyor. HDD kullanan build sunucularınız varsa (evet, hâlâ var böyle yerler, bizzat gördüm) fark çok daha dramatik olabilir. İlgili PR: Microsoft/vcpkg-tool#1896.
# vcpkg manifest modunda tipik kullanım
# vcpkg.json dosyanız varsa:
vcpkg install --triplet x64-linux
# Paralel kurulum otomatik aktif — ekstra bir şey yapmanıza gerek yok
# Eğer eski davranışı istiyorsanız (neden istersiniz bilmiyorum ama):
# Şu an için böyle bir flag yok, varsayılan olarak paralel çalışıyor
Az önce “fena değil” dedim ama aslında şunu da eklemem lazım — beklentim biraz daha yüksekti. 2x falan olsa süper olurdu. Yine de 1.39x bedavaya gelen bir performans artışı, kimse hayır demez.
libcurl Entegrasyonu: Komut Satırından Kütüphaneye Geçiş
Ne yalan söyleyeyim, Bu değişiklik dışarıdan bakınca küçük görünüyor ama altında önemli bir mimarı karar var. vcpkg eskiden dosya indirmek için curl komut satırı aracını çağırıyordu. Şimdi doğrudan libcurl kütüphanesini kullanıyor.
Kısacası, neden önemli? Birkaç sebep var:
- Komut satırı çağrısı yapmak ek process spawn maliyeti getiriyor — düzinelerce paket indirirken bu toplanıyor
- curl’ün farklı sürümlerinin farklı davranışları var, özellikle proxy ayarları ve TLS ayaru konusunda
- Hata yönetimi komut satırı çıktısını parse etmekten çok daha temiz oluyor
- Windows’ta curl’ün yüklü olup olmadığı bile sorun olabiliyordu (evet, Windows 10+ ile geliyor ama eski sistemler…)
2019’da kendi hosting altyapımda benzer bir geçiş yapmıştım — wget komut satırı çağrılarından Python’ın requests kütüphanesine. İndirme güvenilirliği gece gündüz fark etti. vcpkg ekibinin bu adımı atması geç bile kalmış aslında.
Dependency Resolution Optimizasyonu ve Topluluk Katkıları
Bağımlılık çözümleme performansının iyileştirilmesi — bunu yapan @dg0yt adlı bir topluluk üyesi. Açık kaynak dünyasının güzelliği işte bu. Microsoft’un dev bir ekibi var ama bazen en kritik optimize etmeları dışarıdan biri yapıyor. Daha fazla bilgi için Azure SQL’de Vektörler ve Analitik: ETL Neden Geride Kalıyor? yazımıza bakabilirsiniz.
Ha, bir de şunu söyleyeyim: 158 topluluk katkıcısı commit yapmış bu dönemde. 7.400+ fork, 26.800+ star. Bu rakamlar vcpkg’nın artık “deneysel bir araç” olmadığını, ciddi bir dünya olduğunu gösteriyor.
Unix’te Çalıştırma İzni Sorunu
@zynfly’ın düzelttiği bir bug vardı — indirilen araçlarda çalıştırma izinlerinin eksik olması (yanlış duymadınız). Linux’ta vcpkg kullananlar bunu muhtemelen yaşamıştır. Ben 2024’te bir Ubuntu build sunucusunda tam da bu sorunla karşılaştım, chmod +x ile geçici çözüm bulmuştum (inanın bana). Artık buna gerek yok.
Visual Studio VCPKG_ROOT Uyarısı
Bakın, ne yalan söyleyeyim, Bir dakika, şunu da ekleyeyim: Visual Studio’nun kendi vcpkg kurulumu ile sistem genelindeki vcpkg arasında VCPKG_ROOT uyumsuzluğu uyarıları düzeltilmiş. Bu problem beni deli ediyordu. Bir projede VS entegre vcpkg, diğerinde standalone vcpkg kullandığınızda sürekli uyarı alıyordunuz. Sonunda düzeltmişler, çok şükür. Bu konuyla ilgili Codex’te Fiyat Meselesi Değişti: Takımlar İçin Ne Anlama Geliyor? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için OpenAI Neden Bir Medya Şirketi Satın Aldı: TBPN yazımıza bakabilirsiniz.
additional_file girişlerinin deduplikasyonu da bu sürüme girdi. Eğer büyük bir ekipte çalışıyorsanız ve binary caching kullanıyorsanız, cache boyutunuz küçülecek ve isabet oranınız artacak. PR: Microsoft/vcpkg-tool#1914
Triplet Bazında Port Mevcudiyeti: Büyük Resim
İşin sayısal tarafına bakalım. vcpkg’nın test edilen triplet’lere göre mevcut port sayıları bayağı ilginç bir tablo çiziyor: Bu konuyla ilgili Azure Boards’ta Markdown Düzenleyici Neden Daha Sakin Oldu? yazımıza da göz atmanızı tavsiye ederim.
| Triplet | Mevcut Port Sayısı |
|---|---|
| x64-linux | 2.725 |
| x64-windows | 2.714 |
| x64-windows-static | 2.594 |
| x86-windows | 2.583 |
| arm64-osx | 2.528 |
| arm64-windows | 2.346 |
| x64-android | 2.197 |
| arm64-android | 2.144 |
| arm-neon-android | 2.135 |
| arm64-linux | 2.091 |
Dikkat ederseniz x64-linux en yüksek port sayısına sahip. Bu beni biraz şaşırttı — Windows değil de Linux önde mi? Aslında mantıklı, çünkü açık kaynak kütüphanelerin çoğu Linux-first geliştiriliyor. Windows portları bazen ek yama gerektiriyor. Bu konuyla ilgili Yapay Zekâ Çağında Sanayi Politikası: Asıl Mesela Ne? yazımıza da göz atmanızı tavsiye ederim.
Hmm, bunu nasıl anlatsamdı…
Bir de arm64-linux’un 2.091 ile en düşükte olması dikkat çekici. ARM sunucular hızla yaygınlaşıyor (Azure’da bile Ampere tabanlı VM’ler var artık) ama kütüphane desteği henüz tam olgunlaşmamış (ben de ilk duyduğumda şaşırmıştım). Küçük bir startup ARM Linux üzerinde geliştirme yapıyorsa, bazı kütüphanelerin eksik olabileceğini göz önünde bulundurmalı.
Dokümantasyon Güncellemeleri ve Maintainer Rehberi
Küçük bir detay: Bakın şimdi, bu kısım genelde kimsenin ilgisini çekmiyor ama bence en önemli değişikliklerden biri. vcpkg maintainer rehberi güncellendi — port olgunluğu, proje aktivitesi, port isimlendirme kuralları. PR inceleme beklentileri yeniden düzenlendi.
Neden önemli? Çünkü vcpkg’ye port eklemek isteyen herkes bu rehbere bakıyor. Rehber ne kadar net olursa, gelen portların kalitesi o kadar yüksek oluyor (evet, doğru duydunuz). Ben bir arkadaşımın kendi kütüphanesini vcpkg’ye ekleme sürecine yardım etmiştim, 2024’te. O zamanki rehber biraz belirsizdi, özellikle “port ne kadar olgun olmalı” konusunda. Şimdi bu netleşmiş, güzel bir gelişme.
Ha bu arada, GitHub’da Güvenlik Sekmesi Değişti: Kalite de Eklendi yazımda bahsettiğim kalite odaklı yaklaşım burada da kendini gösteriyor. Ekosistemler olgunlaştıkça kalite standartları da yükseliyor.
Enterprise vs Startup: Bu Güncellemeler Kimi Nasıl Etkiliyor?
Yanı, Kurumsal tarafta çalışan biri olarak şunu söyleyebilirim — paralel kurulum ve binary cache iyileştirmesi enterprise CI/CD pipeline’ları için ciddi zaman ve maliyet tasarrufu demek. Düşünün, günde 50 build yapan bir ekipte her build’den 1 dakika kazanmak, ayda 25 saat demek. Bu da para.
Burada, küçük bir startup için? Aslında… dur bir saniye, önce şunu söyleyeyim: küçük ekipler genelde vcpkg’yi lokal geliştirmede kullanıyor. CI/CD’leri daha basit. Onlar için OpenSSL güvenlik yaması çok daha kritik, çünkü güvenlik ekipleri yok, bu tür şeyleri takip edecek kapasiteleri sınırlı.
Şöyle söyleyeyim, Bence en önemli çıkarım şu: vcpkg artık sadece “kütüphane indirme aracı” değil, ciddi bir build altyapısı parçası hâline geldi. Ve buna göre muamele etmek lazım — sürüm takibi, güvenlik yamaları, performans optimizasyonu dahil.
Bence, Bitirmeden önce: Visual Studio’da Copilot Mart 2026: Ajan Devrimi yazımda Visual Studio ortamindeki hızlı değişimlerden bahsetmiştim (kendi tecrübem). vcpkg de bu ekosistemin ayrılmaz bir parçası ve aynı hızla evrimleşiyor.
Sıkça Sorulan Sorular
vcpkg’yi güncellemem şart mı yoksa sadece OpenSSL’i mi yamamalıyım?
Açık konuşayım, İkisi de mümkün. Eğer sadece güvenlik yamasını istiyorsanız OpenSSL sürümünü 3.6.1#3 veya sonrasına override edebilirsiniz (ki bu çoğu kişinin gözünden kaçıyor). Ama paralel kurulum ve diğer performans iyileştirmelerinden faydalanmak için tam güncelleme yapmanızı tavsiye ederim. Zaten breaking change yok bu sürümlerde.
Paralel dosya kurulumu için ekstra bir ayar yapmam gerekiyor mu?
Hayır, büyük ölçüde otomatik. vcpkg tool sürümünüzü güncelledikten sonra paralel kurulum varsayılan olarak aktif. Herhangi bir flag veya ayar değişikliği gerektirmiyor. Sadece tool binary’nizi güncellemeniz yeterli.
Binary cache hit rate iyileştirmesi mevcut cache’ımı bozar mı?
Kısa cevap: hayır. Ama ilk build’de bazı paketler yeniden derlenebilir çünkü ABI hash’leri değişmiş olabilir. Uzun vadede cache boyutunuz küçülecek ve isabet oranınız artacak. Geçiş süreci sorunsuz.
arm64-linux triplet’inde neden bu kadar az port var?
ARM64 Linux desteği diğer platformlara göre daha yeni ve bazı kütüphanelerin ARM derlemesi ek patch gerektiriyor. Port sayısı her sürümde artıyor ama x64 platformlarına yetişmesi biraz zaman alacak. Eğer ARM Linux hedefliyorsanız, kullandığınız kütüphanelerin desteklenip desteklenmediğini önceden kontrol edin (en azından benim deneyimim böyle)
vcpkg’nın Conan veya Hunter gibi alternatiflerden farkı nedir?
vcpkg Microsoft destekli, Visual Studio ile doğal entegre. Curated registry yaklaşımıyla port kalitesini garanti altına alıyor. Conan daha esnek ama konfigürasyonu daha karmaşık. Hunter işe daha niş. Enterprise ortamda VS kullanıyorsanız vcpkg en az sürtünmeyle çalışan seçenek — bunu deneyimle söylüyorum.
Kaynaklar ve İleri Okuma
What’s New in vcpkg (Feb 2026 – Mar 2026) — Microsoft C++ Blog
vcpkg Resmî Dokümantasyonu — Microsoft Learn
İçeriği paylaş:
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Ebru G.
Paralel kurulum özelliği uzun zamandır beklenen bir şeydi, büyük projelerde bağımlılık kurulumu gerçekten çok vakit alıyordu. CVE-2026-34054 yamasını da zamanında yapmak gerekiyor, OpenSSL tarafını es geçmeyin derim. Bu arada şu yazınız da güzeldi: Azure SQL’de Vektörler ve Analitik: ETL Neden Geride Kalıyor? https://www.askinkilic.com.tr/azure-sqlde-vektorler-ve-analitik-etl-neden-geride-kaliyor/
Ahmet Y.
OpenSSL yamasını görünce hemen güncelleme yaptım, CVE numaralı açıklar her zaman öncelikli oluyor. Paralel kurulum özelliği de uzun süredir beklenen bir şeydi, büyük projelerde bağımlılık kurulumları gerçekten çok vakit alıyordu.
Fatma B.
Paralel kurulum gerçekten uzun süredir beklenen bir şeydi, büyük projelerde vcpkg’nin yavaşlığı can sıkıcı oluyordu. CVE düzeltmesini de atlamadan dahil etmişler, güzel. Bu arada şu yazınız da güzeldi: Codex’te Fiyat Meselesi Değişti: Takımlar İçin Ne Anlama Geliyor? https://www.askinkilic.com.tr/codexte-fiyat-meselesi-degisti-takimlar-icin-ne-anlama-geliy/
Sibel V.
Paralel kurulum kısmı gerçekten beklenen bir özellikti, büyük projelerde kurulum süreleri had safhaya gelmişti. CVE fix’i için de iyi ki hızlı davranmışlar, Windows’ta registry bekleme meselesi epey can sıkıcıydı.









4 comments