Copilot CLI’da C++ Dil Sunucusu: Kurulum Çilesi Bitiyor mu?
Şunu net söyleyeyim: C++ projelerinde IDE’nın dışına çıkınca, o meşhur “kod zekası” bir anda biraz buharlaşıyor. Visual Studio ya da CLion açıkken — ki bu tartışılır — her şey yolunda gidiyor, git tanıma çalışıyor, semboller bulunuyor, refactor araçları da fena sayılmaz; ama terminale düşüp uzak bir Linux makinede build almaya başlayınca tablo değişiyor. İşte Microsoft’un yeni duyurduğu C++ language server plugin, Copilot CLI tarafında tam da bu boşluğu kapatmaya uğraşıyor (buna dikkat edin)
Şunu söyleyeyim, Ben Azure tarafında uzun süredir danışmanlık yapıyorum,. Müşterilerin önemli bir kısmı hâlâ devasa C++ kod tabanlarıyla boğuşuyor. Finans tarafındaki düşük gecikmeli sistemler, oyun motorları, gömülü tarafta üretim hattı yazılımları… Hepsinde aynı dert var aslında: build sistemi karışık, IDE her zaman elinizin altında değil, bir de yapay zekâ destekli araçların kodu “bir şekilde anlaması” gerekiyor. Bu yazıda yeni eklentinin ne yaptığını, nerede iş gördüğünü ve nerede biraz tökezlediğini kurcalayalım (bu konuda ikircikliyim)
Mesele aslında compile_commands.json meselesi
C++ dünyasında işin sırrı çoğu zaman tek bir dosyada saklı: compile_commands.json. Bu dosya, her kaynak dosyanın hangi flag’lerle, hangi include path’leriyle, hangi tanımlarla derlendiğini anlatan bir tür harita. Clangd da bakıyor buna, ccls de bakıyor, Visual Studio’nun open folder modu da bakıyor; yoksa dil sunucusu kör kalıyor, lafı gevelemeden söyleyeyim.
İşte tam da bu noktada devreye giriyor.
Açıkçası, Bu dosyayı üretmek şimdiye kadar bayağı baş ağrısıydı. CMake tarafında işler daha kolay — bir flag geçiyorsunuz, dosya oluşuyor. Ama MSBuild tarafında? Ya da kendi yazdığınız özel bir build pipeline varsa? Orada iş sarpa sarıyor (ciddiyim). Sahada sık gördüğüm şey şu: ekip lideri compile_commands.json’ı bir kere üretiyor, repo’ya commit ediyor, sonra üç ay geçiyor, dependency’ler değişiyor. Kimse artık bunun nasıl üretildiğini hatırlamıyor. Sonra da “kod zekası bozuldu” diye ticket açılıyor; hani sorun sanki araçta değilmiş gibi.
Yeni eklenti tam burada devreye giriyor. Copilot CLI’a kurduğunuzda size bir setup LSP skill veriyor; yanı Copilot’a “regenerate compile commands” ya da “load project” dediğinizde projenin tipini koklayıp uygun üretim adımlarını kendisi tetikliyor (bizzat test ettim). CMake için ayrı bir yol var, MSBuild için başka bir yol var, özel build sistemlerinde işe kendi skill’ınızı yazma seçeneği bırakılmış. Fena değil açıkçası.
Kurulum: Tek satır, ama detayları var
Kurulum gerçekten tek satıra kadar inmiş:
/plugin install cpp-language-server@copilot-plugins
Araya gireyim: Bu komutu Copilot CLI içinde çalıştırdığınız anda eklenti Copilot Plugins marketplace üzerinden geliyor. Sonrasında EULA kabulü — en azından ben öyle düşünüyorum — ve compile_commands.json ayaru adımları çıkıyor karşınıza. Buraya kadar tamam; ama dur bir saniye — pratikte önceden bilmeniz gereken birkaç küçük nokta var.
Birincisi şu: build yapılandırmaunuz değişirse (yeni dependency, yeni preprocessor define, yeni hedef platform), skill’i yeniden tetiklemeniz gerekiyor. Microsoft buna “skill’i re-invoke et” diyor. LSP server compile_commands.json dosyasını izliyor. Dosya değişince senkronize oluyor — ama o dosyanın güncel kalması yine sizin sorumluluğunuzda. Bunu otomasyona bağlamak isteyenler için CI step’i ya da pre-commit hook baya işe yarar bence.
Durun, bir saniye.
Hangi proje tipi, hangi yol?
Doğrusu, Eklenti üç farklı proje tipi için üç farklı yaklaşım sunuyor. Bunu düz bir tabloyla görmek daha rahat:
| Proje Tipi | Önerilen Yol | Dikkat Edilecek |
|---|---|---|
| CMake | Skill ile otomatik üretim veya -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE |
Out-of-source build dizini ile root karışırsa skill sembolik link önerebiliyor |
| MSBuild | Skill rehberli kurulum veya manuel compile_commands.json |
vcxproj dosyalarının configuration’ları skill tarafından okunuyor, ama özel target’lar için elle düzeltme gerekebilir |
| Özel build sistemi | Proje-spesifik kendi skill’ınızı yazın | Bir kez yazıp repo’ya koymanız ekibin geri kalanını rahatlatır |
Bunu yaşayan biri olarak söyleyeyim, CMake tarafı en rahat olanı, tartışmasız. Zaten native desteği var; skill sadece işi hızlandırıyor. MSBuild tarafında işe yıllardır çekilen çile biraz azalıyor — çünkü vcxproj dosyalarını parse edip compile commands’a çevirmek hiç hafif iş değildi. Şey yanı, dışarıdan basit görünüyor ama içeride epey kıvrım var.
Peki bu pratikte ne kazandırıyor?
Açık konuşayım: Eğer sız hâlâ Visual Studio’nun içinden çıkmıyorsanız bu eklenti çok fazla şey katmayabilir. Zaten elinizde iyi çalışan başka araçlar var. Ama şu senaryolar varsa hikâye değişiyor:
- SSH ile uzak bir Linux build sunucusuna bağlanıp orada kod yazıyorsanız
- Büyük bir monorepo içinde çalışıyorsanız ve aynı anda birkaç repo parçasıyla uğraşıyorsanız
- Build süresi 20 dakikayı aşıyorsa ve IDE indexleme yapmaya bile üşeniyorsa — ciddi fark yaratıyor
- Kod incelemesini terminal üzerinden hızlıca AI yardımıyla yapmak istiyorsanız
- Container içinde dev container kullanıyorsanız ve IDE bazen tutarsız davranıyorsa
Bakın, Böyle durumlarda Copilot CLI’a semantik zekâ eklemek gerçekten fark yaratıyor. “Bu fonksiyonu nereden — en azından ben öyle düşünüyorum — çağıran var?” sorusuna grep yerine gerçek sembol grafiğiyle cevap vermesi güzel mesela; hatta “bu header’ı dahil etmesem ne kırılır?” sorusunda tahmin yürütmek yerine dependency graph’a bakması daha dürüst sonuç veriyor. Peki neden önemli? Çünkü C++ zaten yeterince sürpriz çıkarıyor. Daha fazla bilgi için OpenAI ve Broadcom’dan Jalapeño: LLM’e Özel Çip Geliyor yazımıza bakabilirsiniz.
LSP’nın gücüyle AI’ın hayal gücü birleşince ortaya ilginç bir şey çıkıyor. Copilot artık “sanırım şu fonksiyonu kastediyorsun” demek yerine, gerçekten kastettiğiniz fonksiyonu compile commands üzerinden bulmaya çalışıyor. Küçük fark gibi dürüyor ama halüsinasyon oranını gözle görülür biçimde aşağı çekiyor.
Türkiye’deki C++ ekipleri için durum nedir?
Bende oluşan izlenim şu: Türkiye’de C++ kullanımı iki uçta yoğunlaşıyor. Bir tarafta savunma sanayi ve — kendi adıma konuşayım — gömülü sistemler var; burada genelde özel build sistemleri, kapalı network’ler ve sertifikalı toolchain’ler dönüyor (bizzat test ettim). Diğer tarafta fintech ve oyun stüdyoları dürüyor; onlar daha modern tarafa yakınlar, CMake kullanan çok oluyor, Bazel deneyenleri de gördüm açıkçası.
Bir dakika — bununla bitmedi.
İlk gruba söyleyeceğim şey biraz soğuk olacak. Gerçek bu: Copilot CLI’ı kapalı ağ ortamlarında kullanmak tek başına problem çıkarabiliyor. Eğer şirketinizde GitHub Enterprise Cloud ya da Azure tarafında Copilot Business/Enterprise lisansı varsa ve proxy üzerinden erişim sağlanabiliyorsa eklenti çalışır. Aksi hâlde önce altyapıyı çözmek gerekiyor; bu da ayrı maliyet demek — kullanıcı başına aylık 19 dolar bandı var ve kur farkıyla beraber 100 kişilik ekipte yıllık bütçe küçücük kalmıyor (yanlış duymadınız)
İkinci grup için durum daha sade. CMake zaten yaygın kullanılıyor, build sunucuları çoğu zaman Linux üzerinde koşuyor, geliştiriciler hem WSL hem native Linux kullanabiliyor. Bu eklenti onlar için daha az sürtünmeli bir entegrasyon olacak gibi dürüyor. Buna paralel olarak MSVC tarafında GitHub Copilot Modernization C++ İçin GA: MSVC Yükseltmesi Artık Kolay yazımdaki modernization feature’larıyla birlikte düşününce eski C++ kod tabanlarını yenilemek için elde ciddi seçenek oluşuyor. Daha fazla bilgi için Azure Functions MCP Extension Build 2026: Yenilikler ve Saha Notları yazımıza bakabilirsiniz.
Peki neden?
Startup vs Enterprise: Hangi senaryoda mantıklı?
Küçük bir ekipseniz — diyelim 5-10 kişilik startup ve tek bir C++ servisiniz var — bence direkt CMake + skill kombinasyonuyla başlayın (bizzat test ettim). Yarım günde kurulum biter gibi oluyor; ekip de hemen hızlanır. E peki, sonuç ne öldü? Karmaşık konfigürasyonlara dalmaya gerek yok.
Şahsen, Ama 200+ geliştiricili kurumsal yapıda durum başka akıyor doğal olarak (kurum olunca her şey biraz uzuyor). Önce şunları yapın:
- Pilot takım seçin (5-8 kişi), bir aylık deneme yapın
compile_commands.jsonüretimini CI pipeline’a bağlayın — manuel kalmasın — ciddi fark yaratıyor- Özel build sisteminiz varsa proje-spesifik skill’i bir kez yazın ve internal package olarak dağıtın
- Güvenlik ekibinizle Copilot CLI’ın hangi telemetriyi gönderdiğini netleştirin
- Daha geniş yaymadan önce verimlilik kazanımını ölçün — boş beklentiye gerek yok
Ekşi yönleri de var tabiî
Şimdi madalyonun diğer yüzüne gelelim. Her yeni özellik gibi bunun da hâlâ pişmesi gereken yanları var. Daha fazla bilgi için Azure SDK Mayıs 2026: Rust GA, AI Search ve Agent Server yazımıza bakabilirsiniz. Daha fazla bilgi için Azure DevOps Issuer Emekliye Ayrılıyor: WIF Geçişi Şart yazımıza bakabilirsiniz.
Biri şu: özel build sistemleri için “kendi skill’ını yaz” çözümü kağıt üstünde hoş dürüyor ama pratikte herkes bunu çıkarıp yazacak kapasiteye sahip değil maalesef. Bazel için resmî bir şablon olsa bir düşüneyim… ya da Make-based projelerde bear veya compdb gibi araçlarla köprü kuran hazır entegrasyonlar gelse hayat daha kolay olurdu sanki. Şimdilik çoğu ekibin Bazel tarafında bazel-compdb gibi üçüncü parti araçlara yaslanması gerekecek gibi görünüyor.
Yanı, Daha büyüğü şu olabilir: büyük monorepo’larda compile_commands.json dosyası rahatça yüzlerce megabayta ulaşabiliyor. LSP server’ın bunu her değişiklikte ne kadar verimli işlediği konusunda elimde henüz tam test yok açıkçası. Eğer sizde bu dosya 50 MB’ı geçiyorsa ilk indeksleme sırasında sabrınız biraz zorlanabilir. JetBrains Copilot Artık CLI Üzerinde Çalışacak: Ne Değişiyor? yazımızda bu konuya da değinmiştik.
Dürüst olmak gerekirse, Bir de CLI tarafındaki semantik refactor kalitesi hâlâ IDE seviyesinde değil gibi hissediyorum ben (ben de ilk duyduğumda şaşırmıştım). “Bu fonksiyonu yeniden adlandır” dediğinizde IDE’nın verdiği güven duygusu burada tam yok. Küçük dokunuşlar — import ekle, sembol bul, hata açıkla — gayet iyi gidiyor ama büyük dönüşümler için yine IDE ya da dedicated refactoring tool lazım oluyor.
Kullanmak isteyenler için pratik başlangıç rehberi
Denemek isteyenlere somut adımlar bırakayım:
- Kullandığınız Copilot CLI sürümünü güncelleyin;
/plugin install cpp-language-server@copilot-pluginskomutuyla eklentiyi kurun;- EULA’yı kabul edin (kurumsal ortamdaysanız hukuk ekibine göstermek fena fikir değil);
- load project”> deyin;
- >Skill projenizin CMakeLists.txt ya da.vcxproj dosyasını tespit edip size yön gösterecek;>
Üretilen>compile_commands.jsonSıkça Sorulan Sorular
Bu eklenti ücretsiz mi, Copilot lisansı gerekiyor mu?
Eklentinin kendisi Copilot Plugins marketplace'inden ücretsiz kurulabiliyor. Ama Copilot CLI'ı kullanmak için aktif bir GitHub Copilot aboneliğine ihtiyacın var. Individual, Business veya Enterprise — aslında hangisi olursa olsun temel ihtiyacı karşılıyor. Kurumsal kullanım söz konusuysa bence Business veya Enterprise'a geçmek daha mantıklı, çünkü telemetri kontrolü ve veri politikaları çok daha katı oluyor.
compile_commands.json dosyasını git repo'ya commit'lemeli miyim?
Genelde hayır, etme. Bu dosya hani build ortamına özgü mutlak yollar içerebiliyor, yani her geliştiricinin makinesinde farklı çıkıyor. Tecrübeme göre en sağlıklısı.gitignore'a ekleyip CI veya bir setup script aracılığıyla her klonlamada otomatik üretilmesini sağlamak. CMake projelerinde
-DCMAKE_EXPORT_COMPILE_COMMANDS=TRUEflag'ini varsayılan yapman da güzel bir alışkanlık.Visual Studio veya CLion kullanıyorsam bu eklentiye ihtiyacım var mı?
Hayır, yok. Bu eklenti spesifik olarak Copilot CLI için — yani terminal üzerinden Copilot kullananları hedefliyor. IDE'ler zaten kendi LSP entegrasyonunu hallediyor. Ama mesela SSH ile uzak bir makinede çalışıyorsan ya da IDE açmadan hızlıca bir kod analizi yapmak istiyorsan, açıkçası eklenti işini bayağı kolaylaştırıyor.
Özel bir build sistemim var (Bazel, Buck, kendi script'imiz). Ne yapmalıyım?
İki seçeneğin var. Ya elle bir
compile_commands.jsonüretip eklentiye gösterirsin — mesela Bazel içinbazel-compdb, Buck için de benzer üçüncü parti araçlar mevcut. Peki, ya da kendi proje-spesifik skill'ini yazıp repo'ya eklersin. İkinci seçenek başta biraz efor istiyor,. Bence uzun vadede kazançlı çünkü ekibinin geri kalanı için tekrarlanabilir bir kurulum sağlıyor.Eklenti uzak Linux sunucuda çalışır mı?
Evet, gayet güzel çalışıyor. Hatta asıl hedef kitlesi de bu zaten — uzak Linux build makinelerinde SSH ile çalışan geliştiriciler (ben de ilk duyduğumda şaşırmıştım). Dikkat etmen gereken iki şey var: Copilot CLI'ın o sunucudan çıkış internet erişimi olması ve authentication token'ların düzgün set edilmesi. Kurumsal bir proxy arkasındaysan HTTP_PROXY ve HTTPS_PROXY environment değişkenlerini doğru ayarlamayı sakın atlama.
Kaynaklar ve İleri Okuma
Şimdi, dürüst olmak gerekirse, Microsoft C++ Team Blog: Streamline C++ Code Intelligence Setup in Copilot CLI
Microsoft Learn: CMake Presets ve compile_commands.json Üretimi
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.








0 comments