Ninja’nın (2020) Başarısı ve Başarısızlığı

 (neugierig.org)
2 puan yazan GN⁺ 2024-11-30 | 1 yorum | WhatsApp'ta paylaş
  • 2011’de yayımlanan Ninja, Make’e benzer bir build sistemi olarak başlayıp Chrome, Android’in bazı bölümleri, Meson ve CMake tabanlı projelere kadar yayılan, önde gelen bir açık kaynak başarı örneğine dönüştü
  • Başarıyı ve başarısızlığı belirleyen eksen, kodun kendisinden çok mimari, hatta bakım ve kullanıcı beklentileri gibi sosyal meseleler oldu
  • Ninja, ninja.build dosyasında yazılı komutları, girdileri ve çıktıları okur; dosya değiştirilme zamanlarını kontrol eder ve gerekli işleri paralel çalıştırır. Büyük projelerde incremental build’leri hızlı hale getirmeye odaklanır
  • En büyük tasarım tercihi, üst seviye build özelliklerini doğrudan içinde barındırmamak ve bir action graph çalıştırıcısı olarak kalmaktı; karmaşık kararlar generator’a bırakılacak şekilde ayrıldı
  • CMake entegrasyonu, Windows desteği ve paralel çalıştırmanın varsayılan olması yayılmayı hızlandırdı; ancak tasarım hedefleriyle çatışan talepler ve katkılar, açık kaynak bakımında büyük bir yük olarak kaldı

Ninja’nın yaygınlaşmasının bağlamı

  • Ninja, yaklaşık 9 yıl önce yayımlanan, Make’e benzer bir build sistemidir; başlangıçta biraz utanarak paylaşılan bir yan projeydi, ancak sonrasında yaygın biçimde kullanılmaya başladı
  • Başlıca kullanım örnekleri şunlardır
    • Chrome sonunda Ninja olmayan build seçeneklerinin tamamını kaldırdı
    • Android, sistemin bazı büyük bileşenlerinde Ninja kullanıyor
    • Meson projesi Ninja kullanıyor ve özgür yazılım dünyasında giderek daha çok kullanılan bir build sistemi gibi görünüyor
    • CMake ile birlikte Ninja kullanan çok sayıda proje var; Swift build yönergeleri de Ninja kurulmasını istiyor
  • Ninja 2011’de yayımlandı, 2014’te proje sahipliği devredildi ve daha sonra üçüncü ana bakımcıya geçti
  • Bu değerlendirmeden çıkan temel deneyim, koddan çok mimarinin, mimariden de çok sosyal meselelerin daha büyük etki yarattığıdır

Hızlı build için temel çalışma biçimi

  • Ninja’nın yaptığı iş görece basittir
    • Kullanıcı, ninja.build dosyasına çalıştırılacak komutları, her komutun tükettiği dosyaları ve ürettiği dosyaları yazar
    • Ninja bu dosyayı okur ve çeşitli dosyaların değiştirilme zamanlarını kontrol eder
    • Güncel duruma ulaşmak için gereken komutları paralel olarak çalıştırır
  • Make ile karşılaştırıldığında, girdi build dilinin özellikleri daha azdır; az sayıda işi çok hızlı yapmaya odaklanan bir yapıdadır
  • Çalışma akışı üç aşamaya ayrılır
    • Build dosyasını parse etme ve yorumlama
    • Girdi dosyalarının değiştirilme zamanlarını kontrol etme
    • Gerekli komutları çalıştırma
  • Amaç, 100 bini aşan girdi dosyasına sahip büyük projelerde bile üçüncü aşamaya mümkün olduğunca hızlı ulaşmaktır
  • Örnek bir optimizasyon olarak Ninja, girdi dosya yollarını mümkün olan en erken noktada benzersiz bellek nesnelerine eşler ve daha sonra yol eşitliği karşılaştırmalarında pointer karşılaştırması kullanır
  • Daha düşük seviyeli performans ayrıntıları The Performance of Open Source Software’in Ninja bölümü içinde ele alınır
  • Yıllar içinde Ninja’nın yeniden uygulamaları da ortaya çıktı
    • llbuild ve Shake Ninja dosyalarını girdi olarak destekler
    • samurai neredeyse dosya dosya yeniden uygulanmış bir projedir; daha az koda sahiptir, ancak daha az özelliği vardır ve testleri yoktur
  • Eğlenceli olan %20’lik uygulamayı yapmak kolaydır; kalan %80 ise çok sayıda ayrıntı içerir ve daha hızlı bir uygulama bilinmemektedir

Tasarımda önemli olan tercihler

  • Graph temsili

    • Make, tek bir build kuralının birden fazla dosya ürettiği durumları iyi ele alamaz
    • Ninja, dosyalar arası bir graph yerine dosyalar ile komutlar arasında bipartite graph kullanır
    • Dosya düğümleri komut düğümlerine giren kenarlar olur; komut düğümleri de çıktı dosyalarına giden kenarlara sahiptir
    • Bu yapı build’in gerçek biçimini daha iyi yakalar
    • Girdilerden biri değişirse komut eski durumda kabul edilir; komut çalıştırıldığında tüm çıktılar güncellenir
    • Belirli bir dosya en fazla bir girdi kenarına sahip olabilir
    • Komut satırının kendisi de komut düğümünün girdisi gibi görülebilir; bu nedenle komut satırı flag’leri değiştiğinde komut ve çıktılar eski duruma düşer

  • deps log ve C header bağımlılıkları

    • C header bağımlılıklarını doğru işlemek için C derleyicisinin ürettiği ek bağımlılık verilerini tüketmek gerekir
    • Bir veritabanı kullanıp kullanmama ile basitlik arasında düşünürken deps log gösterim formatı oluşturuldu
    • Bu format oldukça sıkıştırılmıştır, ancak önemli bir biçimde hâlâ hatalı olan kısımları vardır

  • end-to-end / crash-only tasarım

    • Ninja sürekli çalışan bir daemon process değildir; her çalıştırmada işe baştan başlar
    • Bu tercih, end-to-end principle ve crash-only software yaklaşımından etkilenen bir yapıdır
    • Baştan çalıştırılan yolu hızlı hale getirirseniz ayrı bir “online” kod yoluna gerek kalmaz
    • Bellekte sürekli kalabilen projelerde başlangıç performansı eninde sonunda ihmal edilmeye eğilimlidir

  • Dosya durumunu kontrol etme

    • Build araçlarının bellekte sürekli kalması gerektiği beklentisinin nedenlerinden biri, disk dosyası durumunu cache’lemektir
    • Gerçekte kernel bu bilgiyi zaten bellekte cache’ler; kullanıcı alanında yeniden cache’lemek büyük bir tasarruf sağlamaz
    • Linux’ta dosya durumunu alma işlemi çok hızlıdır ve Ninja bunu tek thread’de işler
    • 10 yıl öncesinin ölçütleriyle “hızlı” sayılan makinelerde bile 30 bin dosyanın stat işlemi onlarca milisaniye içinde yapılabiliyordu

  • Ölçek ve spesifikasyon arasında ödünleşim

    • Deneyim kuralı olarak 2 kat ölçek büyümesi optimizasyonla mümkündür; 10 kat ölçek büyümesi ise yeniden mimarileştirme gerektirir
    • Ninja, o dönemde yaklaşık 30 bin build adımına sahip Chrome build’i odağında tasarlandı
    • Bugün daha küçük ortamlarda da kullanılıyor, ancak bu durumlarda hız avantajına ihtiyaç olmayabilir
    • Android build’i gibi daha büyük ortamlarda ölçek sınırlarına çarpıyor ve farklı bir yaklaşım gerekebilir
    • Ninja, paralel çalıştırma için kullanıcının yeterli bilgi sağlamasını ister, ancak build’in tamamını eksiksiz bilmesini zorunlu kılmaz
    • Doğruluk, kolaylık ve performans arasında ödünleşimler vardır; daha doğru ama kullanışsız bir araç yerine, kolaylık için doğruluğun bir kısmından vazgeçen bir araç tüm ekosistemde daha doğru sonuçlar verebilir

“Assembler” metaforunun yarattığı ayrım

  • Build sistemleri çeşitli üst seviye özellikler sunar ve araçların kendilerini açıklama biçimleri bile birbiriyle karşılaştırılması zor olacak kadar geniştir
  • Ninja’nın temel içgörüsü, hangi üst seviye özellik sunulursa sunulsun, build sisteminin nihayetinde dosyaları güncel tutmak için bir action graph kurmak zorunda olduğudur
  • Ninja yalnızca bu action graph’ı çalıştırır; bunun üzerine hangi generator’ın konulacağını kullanıcıya bırakır
  • Bu iki programın ayrımı başlangıçta Chrome projesine iyi uyduğu için oluşturulmuş bir yapıydı, ancak sonrasında Ninja’nın en önemli katkısı haline geldi
  • Avantajları iki tanedir
    • Ninja’nın kendisi basit ve hızlı kalır
    • *.c dosyalarını glob etmek gibi maliyetli işler generator tarafına itilir
  • Diğer build sistemlerinin tüm işleri tek seferde ele almasının aksine, Ninja yapısı hesaplanmış action graph’ın diske snapshot olarak kaydedilmesini sağlar
  • Sonuçta build’ler arasında action graph cache’lenmiş olur
  • Generator istenildiği kadar üst seviye olabilir
    • Örneğin tüm source tree’yi glob edip adında test geçen dosyaları test olarak bulma yöntemi de mümkündür
  • Geliştirici neyin maliyetini ödeyeceğine kendisi karar vermelidir
    • Generator tüm diski glob edebilir; ama o build’in neden yavaş olduğu da daha görünür hale gelir
  • Generator ile action graph arasındaki ayrım pratikte basit değildir ve Ninja’da da hangi katmanın hangi işi üstleneceğine dair çok sayıda ayrıntı vardır
  • Xcode veya Visual Studio build sistemleri de teoride aynı şekilde ön hesaplama yapıp sonucu snapshot’layabilir, ancak katmanları karıştırma cazibesi nedeniyle bunun iyi işlemediği düşünülür
  • Make, globbing, değişken genişletme, substring, fonksiyon gibi programcılara yönelik özelliklerin tamamını içermeye çalıştı; sonuçta gereken tüm özellikleri ifade etmek için zayıf, ama yavaş Makefile’lar yazmak için yeterince güçlü bir dil haline geldi
  • Ninja bu yönden kaçınmaya çalıştı

Varsayılanlar hissedilen performansı belirler

  • Ninja, istenen komutları varsayılan olarak paralel çalıştırır
  • Make de -j flag’i ile paralel çalıştırma yapabilir, ancak varsayılanı seri çalıştırmadır
  • Makefile’lar, bağımlılıkları yeterince belirtmediği için paralel çalıştırmanın güvenli olmadığı şekilde yazılmaya elverişlidir
  • Ninja tek çekirdekli sistemlerde bile her zaman paralel çalıştırır; bu yüzden bu tür hataları daha erken ortaya çıkarır
  • Ninja’ya iyi uyan programlar genellikle paralel build için de güvenli hale gelir
  • Ninja’nın hatalı bağımlılıkları algılayan gelişmiş bir sistemi yoktur; yanlış build’lerin daha sık gerçekleşmesiyle sorunların görünür hale geldiği bir yapıdır
  • Kullanıcılar çoğu zaman Make’in paralel çalıştırma flag’ini unuttuğu veya bilmediği için, yalnızca tek bir varsayılan bile Ninja’nın gerçek kullanımda Make’ten “iki kattan fazla hızlı” hissedilmesini sağlayabilir
  • Kullanıcının fiilen deneyimlemediği optimizasyonların anlamı küçüktür

Hız açısından önemli olan metrikler

  • Build sistemi performansının birden fazla anlamı vardır
    • Baştan sona tam build’in ne kadar sürdüğü
    • Daha önce build aldıktan sonra tek bir dosyayı değiştirip yeniden build almanın ne kadar sürdüğü
  • Ninja, büyük codebase’lerde incremental build sırasında edit-compile döngüsünü hızlandırmaya odaklanır
  • Ninja ilk oluşturulurken, blaze yani bazel çok hızlı olarak hatırlandığı için onun hızına yetişilmeye çalışıldı
  • Daha sonra bakıldığında, ilgilenilen metriklerde blaze’in özellikle hızlı olmadığı; Java programı olduğu için yardım çıktısının bile yavaş olduğu görüldü
  • Incremental build’e bu kadar takılmanın nedeni, yineleme süresinin programcı memnuniyeti üzerinde büyük etkiye sahip olduğunun düşünülmesiydi
  • Ninja edit-compile döngüsünde kullanılır ve 1 saniye ile 4 saniye arasındaki fark önemlidir
  • “Hızlı”nın anlamını kullanıcıya aktarmak zordur; Ninja kılavuzu küçük projelerde hız etkisinin neredeyse hiç hissedilmeyebileceği konusunda uyarır
  • Ancak “hızlı” iyi pazarlanan bir ifadedir; bu yüzden özellik eksikliğinden hayal kırıklığına uğrayan küçük uygulama kullanıcıları da Ninja kullanmaya çalışır
  • Ninja incremental rebuild’e odaklandı, ancak bazı kullanıcılar tam build performansının da iyileştiğini bildirdi
    • Bunun nedeni Ninja’nın neredeyse hiçbir şey yapmaması, build sırasında az CPU kullanması ve gerçek build işlerinden daha az CPU çalmasıdır
  • Çıktı da çok sadedir
    • Başarılı bir build çoğunlukla yalnızca tek satır çıktı verir
    • Diğer build sistemleri çok sayıda aşama ve zamanlama bilgisi yazdırarak ağır hissedilebilir
  • Az konuşan yapı Ninja’yı daha “yokmuş gibi” hissettirir

Yayılımı büyüten CMake entegrasyonu ve Windows desteği

  • CMake

    • Ninja aslında Chrome’un özel build sistemiyle birlikte kullanılmak üzere oluşturuldu
    • Peter Collingbourne, Ninja’yı daha yaygın kullanılan CMake build sistemine bağlama işini yaptı
    • Bu entegrasyon LLVM çalışması için başladı ve yalnızca CMake tarafında değil Ninja tarafında da yeni semantiklerin eklenmesini gerektirdi
    • Ninja’nın gerçek dünyadaki başarısında en büyük paya sahip kişi olarak Peter gösterilir
    • Daha sonra CMake yazarları entegrasyonu devraldı, ancak isteklere ve endişelere yeterince yanıt veremedi
    • Geliştirici bugüne kadar CMake’i doğrudan hiç kullanmadı

  • Windows

    • Chrome Windows’u da hedeflediği için Ninja da Windows’ta çalışır hale getirildi
    • Windows desteğinin büyük bir bölümü bir katkı sağlayıcı tarafından yazıldı
    • Teknik olarak Windows desteği büyük bir zahmettir
    • Process çalıştırma ve çıktı yakalama, platforma özgü API’leri yeniden öğrenmeyi gerektiren türden farklardır
    • Ninja tasarımı, kernel’in cache’lediği dosyanın son değiştirilme zamanını hızlıca alabilme özelliğine dayanır; Windows’ta ise bu geçerli değildir
    • Buna rağmen Windows, geliştirici ölçeği büyük bir platformdur
    • Linux için iyi araçları paylaşma dürtüsü güçlüdür; Windows araçlarında ise satma dürtüsü güçlü olduğundan ücretsiz sunulan araçlar görece daha azdır
    • İlk Ninja kullanıcıları arasında çok sayıda Windows kullanıcısı olması o dönemde şaşırtıcıydı, ancak Windows geliştirici sayısı çok yüksek olduğu için yalnızca küçük bir kısmının ilgi göstermesi bile kullanıcı olarak görünür hale gelir

İlgili çalışmaları anlamak

  • Ninja başlangıçta hafta sonu demo hack’i gibi başladığı için, oluşturmadan önce ilgili çalışmaları yeterince araştırmamış olmaktan pişmanlık duyuluyor
  • Bir şey yaparken tasarım alanını gerçekten anlamak önemlidir
  • “action graph” terimi Ninja oluşturulurken kullanılan bir ifade değil, Google’ın build sistemi blaze/bazel’den alınan bir terimdir
  • bazel, “library”, “binary” gibi üst seviye target graph’ın komutlardan oluşan action graph ürettiğini açıklar
  • Komut satırı metnini dosya gibi bir girdi olarak görme fikri, incremental computation örneklerinden biridir
  • Incremental computation yalnızca build sistemleriyle değil, UI’daki incrementality ile de bağlantılıdır
  • Jane Street blogunda Incremental tanıtım yazısı bulunur ve React gibi UI oluşturma biçimleriyle de bağlantılıdır
  • "Build Systems à la Carte", build sistemleri bağlamında incremental computation’ı tartışan bir makaledir ve Ninja yazılmadan önce var olsaydı iyi olurdu denilen kaynaklardan biridir

Açık kaynak bakımının yükü

  • Açık kaynak maintainer deneyimi özellikle keyifli değildi
  • Projeye yönelik duygular, birinin güzel sözler söylemesiyle gelen gurur ile daha büyük bir hayal kırıklığının karışımıdır
  • Ücretsiz yayımlamanın sonucunda zaman zaman nazikçe istekte bulunanlar oldu; ancak daha sık şekilde kızgın kullanıcılar taleplerde bulundu ve teşekkürler nadirdi
  • Talepleri kabul edilmezse fork edeceğini söyleyerek tehdit edenler de tekrar tekrar oldu
  • Tasarım hedefleriyle çatışan makul katkılar da başka bir zorluktu
    • Nazik ve zeki birinin yaptığı katkıyı reddetmek gerektiğinde, bunu yeterli bir açıklamayla karşılamak isteniyordu ve açıklamanın kendisi yorucu bir işe dönüşüyordu
  • Programlamaya özgür yazılım sayesinde başlanmış ve alınanı geri vermek için kod yazılmış olsa da, bugünkü özgür yazılım eşitler arası paylaşım olmaktan çok, kullanıcıların kendilerini müşteri gibi görüp yazarı yöneticisine şikâyet edebilecekleri biri olarak ele aldığı bir akışa sahip
  • Bugünkü motivasyon, geniş çaplı başarıdan çok, saygı duyulan az sayıdaki hacker’ı etkilemeye veya onların beklentisini karşılamaya daha yakın
  • Ninja’nın başarısı çok şey öğretti, ancak benzer öğrenimlerin daha küçük bir başarıyla da elde edilebileceği düşünülüyor

Maintainer’lar ve katkı sağlayıcılar

  • Nico Weber dikkatli bir işbirlikçiydi ve yıllar boyunca Ninja maintainer’ı olarak görev yaptı
  • Jan Niklas Hasse, Nico’dan sonra projeyi devraldı ve iyi gidiyor gibi görünüyor
  • Bunların dışında çok sayıda Ninja katkı sağlayıcısı projede yer aldı

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-30
Hacker News görüşleri

  • “Programlamadan kod yazmakmış gibi söz edilir, ama gerçekte mimari koddan daha önemli, sosyal meseleler de mimariden daha önemli hale gelir” ifadesi, uzun zamandır aklımda olan düşünceyi tam olarak dile getiriyor

    • Kesinlikle katılıyorum. Peopleware 1987 [1] de aynı şeyi söylüyor
      Kitabın 1. bölümü “işimizin başlıca sorunları teknik olmaktan çok sosyolojik niteliktedir” diye savunuyor; ekip kimyası ve bağlılığı, “odaklanma zamanı”, sessiz çalışma ortamı, işten ayrılma maliyeti gibi sosyal ve politik meseleleri ele alıyor
      [1] https://en.wikipedia.org/wiki/Peopleware:_Productive_Project...
    • Programlama ve onun araçları bilgisayarlar için değil, insanlar içindir; çok önemsiz işler dışında, bir bilgisayar üzerinde çalışacak bir şey üretmek için birden fazla insana ihtiyaç vardır
      Bu yüzden yazılım mühendisliğinin, pek çok kişinin kabul ettiğinden ya da rahat hissettiğinden çok daha fazla sosyal bilimlere yakın olduğunu düşünüyorum. Sosyal bilimler doğa bilimlerinden daha akışkan ve daha az öngörülebilir olduğundan, sosyal kısmı es geçme ya da onu çok ilkel biçimde ele alma eğilimi var gibi. Teknolojinin atomik ayrıntılarına takıntıyla eğilirken, ekibin ürettiği ürün ise fazlasıyla sık berbat hale geliyor
    • https://en.wikipedia.org/wiki/Conway's_law
      “Sistem tasarlayan kuruluşlar, kaçınılmaz olarak kendi iletişim yapılarını kopyalayan tasarımlar üretir.” — Melvin E. Conway, How Do Committees Invent?
    • Kendi deneyimime göre teknik sorunların kabaca %80'i, iki kişinin ya da iki ekibin sadece karşı karşıya oturup konuşmaktan kaçınmasından kaynaklanıyor
    • Yine de bu bir ikilik değil. İyi mimari, insanların sistemden beklediklerini karşılarken sistemi insanların anlayabileceği halde tutar

  • O dönemde de tartışılmıştı:
    The Success and Failure of Ninja - https://news.ycombinator.com/item?id=23157783 - Mayıs 2020, 38 yorum
    Yaklaşık bir yıl geçince yeniden paylaşım sorun olmuyor; eski başlığın bağlantısı da daha fazlasını merak eden okurlar için

  • “Android’in sistemdeki bazı büyük bileşenler için Ninja kullandığı, ama tam olarak hiç anlamadım” kısmı komik
    Ninja gerçekten de AOSP içinde büyük bir yer tutuyor. Derleme sistemi başlangıçta Makefile kullanıyordu, ancak özel bir deklaratif derleme sistemi olan soong ve başarısız olup durdurulan Bazel geçişi yüzünden hızla karmaşıklaştı. Google, Makefile’ları Ninja derleme dosyalarına dönüştüren kati’yi (https://github.com/google/kati) geliştirdi ve ortaya çıkan çıktı gerçekten devasa:
    λ wc -l out/build-qssi.ninja
    3035442 out/build-qssi.ninja
    Makefile/soong’dan Ninja’ya geçiş süreci sancılı ve güncel makinelerde bile birkaç dakika sürüyor, ama Ninja işi devraldıktan sonra inanılmaz hızlı çalışıyor

    • Ninja’yı hiç kullanmadım; Makefile ile karşılaştırıldığında ne gibi avantajları olduğunu merak ediyorum
      Bir araçtan diğerine çevirmek için bir araç daha devreye sokmaya değip değmediği de şüpheli. Özellikle Ninja dosyası bu kadar büyük ve insanlar için okunması zor olabiliyorsa

  • “Programcıların gecikmeyi hissettiğine ve farkına varmasalar bile ruh hallerinin bundan etkilendiğine inanıyorum. Google yakın zamanda bu alanda bir araştırma yaptı ve inancımı bir ölçüde doğruladı” kısmındaki o gecikme araştırmasının gerçekten yayımlanıp yayımlanmadığını merak ediyorum

  • Ninja, oyun geliştiricileri arasında epey popüler
    “Windows geliştirici tarafında hâlâ devasa bir platform ve o geliştiriciler araçlara aç” cümlesi ilginçti. Ağırlıklı olarak Windows’ta geliştirme yapan biri olarak, iyi bir debugger olan Visual Studio ya da profiler olan Superluminal olmadan yaşayan Linux geliştiricileri bana daha çok araçlara açmış gibi geliyor. Son zamanlarda iki platform arasındaki fark giderek kapanıyor gibi; ayrıca genel olarak çapraz platform çalışan Rust yardımcı araçlarını da seviyorum

    • Biri Visual Studio ile “iyi” kelimesini aynı cümleye her koyduğunda, evrenin bir simülasyon olduğu ve diğer insanların başka evrenlerden geldiği yönünde tuhaf bir hisse kapılıyorum
      Visual Studio ile etkileşimlerim arasında “iyi” denebilecek bir şey aklıma gelmiyor. “Zar zor idare eder” diyebileceğim birkaç şey var, ama debugging bunların içinde değil. Yine de 2022’de debugger artık bug dolu olmadığına göre, belki kastedilen budur
    • Hangi dünyada Visual Studio debugger iyi sayılıyor bilmiyorum. Sonunda düzelttilerse başka, ama en son kullandığımda tek bir satırı adımlamak bile saniyeler sürdürecek kadar dayanılmaz derecede yavaştı
    • UNIX’i geliştirici araçlarının tamamı sanan bir topluluk var ve bu yüzden ağaçları görmeyip ormana bakıyorlar gibi geliyor
      1993’te Xenix ile tanıştıktan sonra çeşitli türevlerini kullanmış olacak kadar UNIX’i iyi bilirim, ama WSL’i Linux Docker container’ları çalıştırmak dışında neredeyse hiç kullanmıyorum

  • Ninja’yı hâlâ kullanan birkaç şeyi samurai’ye çevirdim; mümkün olan her açıdan daha iyi oldu.
    Yine de bu tür build sistemlerinin yönünün yanlış olduğunu düşünüyorum. Bir build sisteminden istediğim şey, tüm geçişli girdilerin içeriklerini hash’leyip sonucun registry’de olup olmadığını sorgulaması.

    • Doğru. Dağıtık cache destekleyen build sistemleri, değişiklik kontrolünde zaman damgaları yerine temelde digest kullanır: Bazel, Pants, Buck vb. böyle.
      Ancak hepsi aşırı karmaşık. Yalnızca yerel build açısından bakarsak SCons ve Waf’ın da değişiklik algılama için hash kullandığını biliyorum.
    • Ninja’nın yazarının yaptığı n2 ilginizi çekebilir.
    • Sanırım NetKernel’in fikri buydu.
      Benzer bir şey olarak Deno kütüphanesi “TDAR”[1]’ı yaptım ve iyi çalışıyor; ama değiştirilebilir bir dosya sistemi üzerinde çalıştığını varsayan komut satırı araçlarını saf fonksiyonlarmış gibi çağırıyormuşçasına sarmalamak biraz uğraştırıyor.
      [1] Henüz üst projeden[2] ayrı çıkarmadım, ama bu YouTube videosunda bundan bahsettim: https://youtu.be/sty29o8sUKI
      [2] Böyle şeylerle ilgileniyorsanız kaynağı açmam için dürtebilirsiniz. togos zero zero at gee mail dot comb
    • Samurai’nin ne açıdan daha iyi olduğunu merak ediyorum. Ninja’nın uyumlu bir alt kümesi sanıyordum.
      Ayrıca “benim istediğim şey değil” demek, “yanlış” demek değildir. Çünkü dünyada zevkleri farklı insanlar da var.
    • Samurai’nin hâlâ yaşayıp yaşamadığını bilmiyorum. sinyal işlemeyi iyileştiren bir pull request gönderdim ama yarım yıldan uzun süredir görmezden geliniyor.

  • CMake’te C++20 modülleri kullanmak için Ninja gerektiğinden, Ninja epey uzun süre varlığını sürdürecek.

  • En ilginç bulduğum kısım, “doğruluk ile kullanım kolaylığı veya performans arasında sık sık ödün vermek gerekir ve bu süreklilikte nerede durduğunuzun bilincinde olmalısınız” bölümüydü.
    Bazı programcılar bu dinamiğe fazla katı bakıyor ve bir taraftaki değerin doğal olarak öncelikli olduğunu düşünüyor. Ama gerçekte etkileşim oldukça incelikli. Örneğin doğruluktan biraz ödün verip kullanım kolaylığını seçen bir araç, daha doğru ama daha az kullanışlı bir alternatife göre tüm ekosistemde daha doğru sonuçlar üretebilir. Programcılar ikincisinden kaçınırsa böyle olur.

    • Bu gerçekten altın değerinde bir içgörü. Bu yüzden Python, Go, TypeScript/JavaScript Haskell/OCaml’dan çok daha popüler.

  • “Utanç verici adı bağışlayın” demiş; adı gayet harika.
    Not: Bunu uygularsanız daha da hızlı hâle getirilebilir: https://github.com/ninja-build/ninja/issues/2157 Ancak yazıda açıklandığı gibi bu araç, önceki çalıştırmadan gelen çok küçük ipuçları dâhil olmak üzere bilerek durum tutmaz.