Windows yerel geliştirme ortamını düzelttim

 (marler8997.github.io)
8 puan yazan GN⁺ 2026-02-16 | 5 yorum | WhatsApp'ta paylaş
  • Windows yerel geliştirme, Visual Studio kurulum bağımlılığı nedeniyle karmaşık ve verimsiz
  • Onlarca GB kurulum boyutu, şeffaf olmayan bileşen yönetimi, sürüm uyumsuzluğu sorunları gibi etkenler geliştirici üretkenliğini düşürüyor
  • Bunu çözmek için hafif bir CLI aracı olan msvcup geliştirildi; MSVC toolchain’i ve Windows SDK’yı sürüme göre, izole biçimde otomatik kurabiliyor
  • msvcup, JSON manifest ayrıştırma, otomatik ortam yapılandırması (autoenv), lock file desteği gibi özelliklerle yeniden üretilebilir bir derleme ortamı sunuyor
  • Bu yaklaşım, Visual Studio Installer’a bağlı kalmadan betik tabanlı tam otomasyonlu bir derleme sistemi kurulmasını mümkün kılıyor

Windows yerel geliştirmenin sorunları

  • Visual Studio kurulmasını gerektiren mevcut yaklaşım, karmaşık kurulum süreci ve kararsız bağımlılık yönetimi nedeniyle geliştiricilere yük getiriyor
    • “Desktop development with C++” workload’u, belirli SDK sürümleri gibi ayrıntılı seçimler gerekiyor; yanlış seçim yapılırsa derleme başarısız olabiliyor
    • Kurulum boyutu 50GB’a kadar çıkıyor ve kaldırıldıktan sonra bile registry kalıntıları ve arka plan servisleri bırakabiliyor
  • Linux’ta toolchain tek satırlık bir paket yöneticisi komutuyla kurulabilirken, Windows’ta binlerce bileşenin elle seçilmesi gerekiyor
  • Visual Studio, editör, derleyici ve SDK’nın birbirine dolandığı tekil bir yapı olduğundan sürüm yönetimi ve ortamın yeniden üretimi zorlaşıyor
  • Sonuç olarak “benim bilgisayarımda çalışıyor” türü tutarsızlıklar sık yaşanıyor; bu da yerel geliştirmenin giriş bariyeri haline geliyor

msvcup: yeni bir yaklaşım

  • msvcup, Visual Studio kurmadan MSVC toolchain’i ve Windows SDK’yı doğrudan indirip kuran açık kaynaklı bir CLI aracı
    • Her sürüm C:\msvcup\ altında izole dizinlere kuruluyor; böylece sürümler çakışmadan paralel kullanılabiliyor
    • Kurulum birkaç dakika içinde tamamlanıyor ve ARM cross-compile araçları da otomatik olarak dahil ediliyor
  • msvcup install komutu gerekli paketleri kuruyor, autoenv komutu ise otomatik ortam dizini oluşturuyor
    • Bu dizin, ortam değişkenlerini otomatik ayarlayan wrapper çalıştırılabilir dosyalar ve toolchain.cmake dosyasını içeriyor; böylece CMake projeleri ek ayar olmadan derlenebiliyor
  • build.bat betiği örneğinde, msvcup ile “Hello, World” programı Visual Studio olmadan derlenebiliyor
    • Windows 10 ve üzeri bir ortamda yalnızca curl ve tar varsa çalışıyor

İç çalışma mantığı

  • Microsoft’un dağıttığı Visual Studio bileşen JSON manifestlerini ayrıştırarak yalnızca gerekli paketleri belirliyor
    • Derleyici, linker, header’lar, kütüphaneler gibi temel bileşenleri doğrudan Microsoft CDN’inden indiriyor
  • Kurulu bileşenler lock file ile yönetiliyor; böylece aynı sürüm paketleri ekip genelinde paylaşılabiliyor
  • install ve autoenv komutları idempotent; yani zaten kuruluysa birkaç milisaniye içinde tamamlanıyor

Gerçek kullanım örneği

  • Tuple (pair programming uygulaması), msvcup’ı CI derleme sistemine entegre ederek Visual Studio’nun önceden kurulmuş olma gereksinimini ortadan kaldırdı
    • WebRTC dahil yüzlerce C/C++ projesi aynı toolchain/SDK ile derlenebiliyor
    • Hem x86_64 hem de ARM derlemelerini destekliyor
  • Avantajlar
    • Sürüme göre dizin kurulumu sayesinde paralel sürüm yönetimi ve kolay yeniden kurulum
    • Cross-compile için otomatik destek, ek yapılandırma gerektirmiyor
    • Lock file tabanlı yeniden üretilebilirlik garantisi, Microsoft tarafındaki değişiklikler anında fark edilebiliyor
    • Hızlı çalışma, gereksiz yeniden kurulum yok

Sınırlamalar ve genişleme

  • msvcup, derleme toolchain’i odaklı tasarlandığı için Visual Studio IDE’sinin kendisinin gerektiği durumlarda resmî kurulum hâlâ gerekli
  • Ancak yerel geliştirme iş akışlarının büyük bölümünde IDE olmadan da tam bir derleme ortamı sunuyor
  • Örnek olarak verilen raylib derleme betiği, Visual Studio olmadan da SDK ve toolchain’i otomatik kurup projeyi derliyor
    • GUI olmadan, yalnızca komut satırıyla tam otomatik bir derleme süreci yürütüyor

Sonuç

  • msvcup, Visual Studio Installer’ın karmaşıklığını ortadan kaldırarak sürüm yönetilebilir, hafif bir yerel derleme ortamı sunuyor
  • Bu yaklaşım, Windows yerel geliştirmeyi yeniden üretilebilir ve otomasyonlu bir yapıya dönüştürüyor; geliştiricilerin IDE bağımlılığından kurtulmasını sağlıyor
  • Repo : https://github.com/marler8997/msvcup

İlgili okumalar

5 yorum

 
GN⁺ 2026-02-16
Hacker News görüşleri

  • Bu, benim yaptığım şeyden daha karmaşık görünüyor
    Sadece LTSC Visual Studio Build Tools kurulup cl yourprogram.c /link user32.lib advapi32.lib ... gibi bir komut bir cmd dosyasına konabilir
    Ben vim ile düzenleme yapıyor ve uzun zamandır çeşitli yardımcı araçları bu şekilde derliyordum
    Visual Studio toolchain'inde LTSC ve kararlı sürümler var ama çoğu kişi bunun farkında değil
    Ekip ortamında, resmî sürüm geçmişi belgesindeki sabit sürümleri kullanmak daha iyi
    Tıpkı eskiden şirket genelinde herkesin aynı toolchain sürümünü sabitlediği zamanlardaki gibi

    • LTSC kanalına erişmek için Visual Studio Professional veya üstü lisans gerekiyor
      Bu yüzden öğrenciler ya da hobi amaçlı geliştirme yapanlar çoğu zaman bunu bilmiyor
      Buna karşılık şirkette VS kullananların çoğu bunu biliyor
    • Visual Studio 2026 için henüz LTSC sürümü yok
      Ne zaman çıkacağını bilen var mı?

  • Linux tarafındaki toolchain de bağımlılık cehenneminden muaf değil
    npm paketi kurarken cmake gerekebiliyor, glibc sürüm çakışmaları çıkabiliyor ya da en yeni boost'u isteyen C++ projeleri olabiliyor…
    Heartbleed döneminde openSSL yaması yapmak zorunda kaldığımı da hatırlıyorum
    Visual Studio da zahmetli ama asıl cehennem .NET Framework sürüm karmaşası
    Her Windows sürümünde kurulu .NET farklı oluyor ve uygulamanın hangi runtime ile çalışacağı da belirsiz kalabiliyor
    Bu yüzden büyük ölçekli dağıtımlarda doğru runtime ile başlatmak için C++ ile .NET sürümü kontrol eden bir shim yazmak gerekiyor

    • Eğer bağımlılık sorunu gerçekten glibc'nin kendisinden kaynaklanıyorsa, bu duyulacak kadar nadirdir
      glibc ekibi geriye ve ileriye dönük uyumluluk konusunda çok katı
      Şu LWN yazısında uyumluluğun en son ne zaman bozulduğu görülebilir
      Sorun, insanların glibc sürümünü yanlış şekilde sabitlemesi
      glibc için sürüm sabitleme yapılmamalı
      GCC birkaç kez uyumluluğu bozdu ama bunun çoğu C++ standardındaki değişikliklerden kaynaklanıyordu
    • Modern .NET artık tamamen farklı
      .NET Framework zaten legacy sayılıyor ve .NET 5 sonrasında bu tür sorunlar yok
      Yine de hâlâ eski sürümlere bağımlı çok uygulama var
    • Eskiden C/C++ geliştirmede yalnızca sistem paket yöneticisi yeterliydi ama daha yeni sürüm ihtiyacı yüzünden dile özel paket yöneticileri ortaya çıktı
      Sorunu çözdüler ama aynı zamanda yeni bir karmaşıklık yarattılar
      Bazen insan sadece sistem paket yöneticisi günlerine dönmek istiyor
    • C/C++ tarafındaki build UX sürtünmesi, bellek güvenliğinden bağımsız olarak sinir bozucu bir nokta
      Gömülü sistemlerde rust + probe-rs tarafı çok daha rahat

  • Visual Studio yükleyicisi, komut satırı parametreleriyle etkileşimsiz kurulumu destekliyor
    Resmî belgede anlatılıyor
    2018'de internetin yavaş olduğu bir uydu ağı ortamında çalışırken çevrimdışı kurulum paketi hazırlamak zorunda kaldığım için bu yöntemi kullanmıştım

    • Denedim ama gereksiz indirme çok fazlaydı ve kurulum yine de yönetici yetkisi gerektiriyordu
    • (Yüksek gecikmeli bağlantı denince… galiba “high-latency” ifadesi daha doğru olur)

  • Betiğe baktım,
    curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...
    şeklinde bir satır var
    Ama kaynağı belirsiz bir GitHub hesabından gelen çalıştırılabilir dosyayı hash doğrulaması olmadan kurmak istemem
    Windows durumu blog yazısında anlatıldığı kadar kötü olmasa da bu, çözümden çok bir başka riskli kurulum betiği gibi duruyor

    • Yürütülebilir dosya kurmak zorunda değilsiniz
      Betiği kendiniz okuyup incelemeniz yeterli
      curl|sh yaklaşımı da sonuçta kaynak kodu indirmekten ibaret; çalıştırılabilir dosyayı doğrudan kurmaktan daha riskli değil
    • Jonathan Marler, Zig sunumları ve win32 API binding çalışmalarıyla tanınan biri
      Onun projesi zigwin32, Microsoft'un win32metadata deposunda da bağlantılanıyor
      Yani güvenilir biri

  • Bu yazı, yapay zeka yazmış gibi hissettiriyor
    “it’s not just X, but Y” gibi cümle yapıları ve vurgulu listeler tipik LLM tarzı
    Projenin ne kadarının insan eliyle yapıldığını merak ediyorum

    • Kullanıcı adının “its_notjack” olması biraz komik
    • Ben de ilk başta şüphelendim
      Liste yapısı garipti ve tutarlılığı zayıftı
      Ama eğer bir LLM yazdıysa bu, bugünkü LLM'lerin kalitesinin epey yükseldiğine dair bir işaret de olabilir
      Grammarly gibi araçların etkisi de olabilir
    • Belki de insanlar artık LLM tarzını taklit etmeye başladı
      Çünkü bu tarz okuyucu için daha kolay okunuyor
    • “The key insight is…” gibi ifadeler Claude'un sık kullandığı bir üslup olduğu için öyle hissettiriyor
      Keşke yapay zeka kullanılıp kullanılmadığı açıkça belirtilse

  • Visual Studio DX'ini iyileştirmeye yönelik bir deneme olarak msvcup gerçekten taze bir fikir
    Keşke üniversite yıllarımda böyle bir şey olsaydı
    Alternatif olarak container içine Build Tools kurma yaklaşımı da var

  • Doğrudan winget ile kurulabilir
    winget install --id Microsoft.VisualStudio.2022.BuildTools
    WinRT özelliklerine ihtiyaç varsa
    winget install --id Microsoft.WindowsSDK.10.0.18362
    winget install --id Microsoft.WindowsAppRuntime.1.8 de eklenebilir

    • Eskiden bu paketler için destek vermiştim ama iş o kadar basit değil
      Hangi workload'ların kurulacağını da belirtmek gerekiyor ve projeyi bilmiyorsanız çok deneme-yanılma yaşanıyor
      .vsconfig biraz yardımcı oluyor ama kusursuz değil

  • Keşke açık kaynak projeleri MinGW desteğini engellemese
    Ek DLL'lere gerek kalmadan gayet iyi çalışan bir derleyici
    Açık kaynak dünyasının neden ille de tekelci bir derleyiciyi dayattığını anlamıyorum

    • MinGW bazı Windows'a özel kütüphanelerle (WIL) uyumlu değil
      WIL, çekirdek geliştiricilerinin sık kullandığı ve kod güvenliğiyle kullanım kolaylığını ciddi biçimde artıran bir kütüphane
    • Dışarıda derlenmiş MSVC kütüphaneleriyle linklemek gerektiğinde MinGW bir seçenek olmuyor
      Örneğin Steamworks SDK, MinGW ile derlenebiliyor ama runtime'da çöküyor
    • Ben de MinGW desteğinin daha yaygın olmasını isterdim
      Bu blog yazısında adının bile geçmemesi üzücü
    • MinGW'yi sevmiyorum
      Clang + MSVC STL + WinSDK kombinasyonu çok daha temiz

  • Ya da daha da basit şekilde şöyle yapılabilir
    "winget install Microsoft.VisualStudio.BuildTools"
    "winget install Microsoft.WindowsSDK.10.0.26100"

    • Ben de hep böyle yapıyorum
      Harcanan çabaya göre sağladığı istikrar iyi olduğu için bunu tercih ediyorum
    • Ama bu tür kurulumlar sistem genelinde oluyor; proje bazında farklı sürümler gerektiğinde sıkıntı çıkıyor
      Keşke tüm diller için Python uv benzeri sürüm yalıtım araçları olsa
    • Windows'a yönelik eleştirilerin önemli bir kısmı 20 yıl öncesinin hikâyesi
      Bing, Copilot, reklamlar gibi şeyler eleştirilebilir ama bunların çoğu devre dışı bırakılabiliyor
 
click 2026-02-16

Ben de Ubuntu 24.04'te derleyip CentOS 6 mı 7'de mi çalıştırmaya kalkınca glibc bağımlılığı sorunu yaşamıştım.
Sorun, varsayılan olarak derleme ortamının glibc sürümünü alıyor gibi görünüyor.
 
penza1 2026-02-18

glibc'ye bağımlı olmak kaçınılmaz..
python/jv/.net/js gibi script dilleri değilse, glibc bağımlılığı olması kaçınılmazdır
Her dağıtıma göre kütüphane dağıtılmasının nedeni de budur
En azından minimum glibc ile derlenen bir şeyin, özel bir bağımlılığı yoksa, diğer daha üst sürüm dağıtımlarda da rahatlıkla çalışabilmesi gerekir
 
geekbini 2026-02-16

WSL2’de Ubuntu ile Windows üzerinde geliştirme yapmak da epey daha iyi hale geldi. Ama ortam VSCode değil de Visual Studio ise, bunun en azından bir miktar faydalı olabileceği anlaşılıyor. Yalnız choco ya da winget gibi paket yöneticileriyle Windows’ta yapılamıyor galiba.
 
click 2026-02-16

Paket yöneticileri, SDK'den ziyade nihai çıktıya odaklanıyor gibi görünüyor
vcredist gibi şeyleri çoğu geliştirici genelde paket yöneticisi betiği içinde kurulacak şekilde ayarlıyor
Ama build ortamı biraz farklı bir konu