Görev Tabanlı Derleme Sistemleri

Sorun bildirme Kaynağı görüntüleme Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Bu sayfada, görev tabanlı derleme sistemleri, bunların işleyiş şekli ve görev tabanlı sistemlerde yaşanabilecek bazı komplikasyonlar ele alınmaktadır. Kabuk komut dosyalarından sonra, göreve dayalı derleme sistemleri, binaların mantıksal evrimidir.

Görev tabanlı derleme sistemlerini anlama

Görev tabanlı bir derleme sisteminde, temel çalışma birimi görevdir. Her biri görev, her türlü mantığı yürütebilen bir komut dosyasıdır. Görevler ise diğer önce çalışması gereken bağımlılıklar olarak düşünebilirsiniz. Kullanılan en önemli derleme sistemleri bugün, Ant, Maven, Gradle, Grunt ve Rake gibi modeller göreve dayalı. Şunun yerine: kabuk komut dosyalarını, çoğu modern derleme sisteminde mühendislerin bir şablondur.

Ant kılavuzundaki şu örneği ele alalım:

<project name="MyProject" default="dist" basedir=".">
   <description>
     simple example build file
   </description>
   <!-- set global properties for this build -->
   <property name="src" location="src"/>
   <property name="build" location="build"/>
   <property name="dist" location="dist"/>

   <target name="init">
     <!-- Create the time stamp -->
     <tstamp/>
     <!-- Create the build directory structure used by compile -->
     <mkdir dir="${build}"/>
   </target>
   <target name="compile" depends="init"
       description="compile the source">
     <!-- Compile the Java code from ${src} into ${build} -->
     <javac srcdir="${src}" destdir="${build}"/>
   </target>
   <target name="dist" depends="compile"
       description="generate the distribution">
     <!-- Create the distribution directory -->
     <mkdir dir="${dist}/lib"/>
     <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
     <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
   </target>
   <target name="clean"
       description="clean up">
     <!-- Delete the ${build} and ${dist} directory trees -->
     <delete dir="${build}"/>
     <delete dir="${dist}"/>
   </target>
</project>

Derleme dosyası XML'de yazılır ve derlemeyle ilgili bazı basit meta verileri tanımlar. ve görev listesi (XML'deki <target> etiketleri) sağlar. (Karınca hedef bir görevi temsil eder ve ifade etmek için görev kelimesini kullanır komutlar gibi). Her görev, Karınca tarafından tanımlanan olası komutların bir listesini yürütür. Bu işlemler arasında dizin oluşturma ve silme, javac çalıştırma ve JAR dosyası oluşturuyoruz. Bu komut grubu, kullanıcı tarafından sağlanan komutlar tarafından genişletilebilir her tür mantığı kapsaması için ekleyebilirsiniz. Her görev, depends özelliği aracılığıyla bağlı olduğu görevleri de tanımlayabilir. Bu bağımlılıklar, Şekil 1'de görüldüğü gibi döngüsel olmayan bir grafik oluşturur.

Şekil 1. Bağımlılıkları gösteren döngüsel olmayan bir grafik

Kullanıcılar, Ant'ın komut satırı aracına görevler sağlayarak derleme yapar. Örneğin, bir kullanıcı ant dist yazdığında Ant aşağıdaki adımları uygular:

Geçerli dizinde build.xml adlı bir dosyayı yükler ve şuna ayrıştırır: Şekil 1'de gösterilen grafik yapısını oluşturabilirsiniz.
Komut satırında sağlanan dist adlı görevi arar ve compile adlı göreve bağımlı olduğunu keşfeder.
compile adlı görevi arar ve bu görevin init adlı göreve bağımlı olduğunu keşfeder.
init adlı görevi arar ve bu görevin bağımlılığı olmadığını keşfeder.
init görevinde tanımlanan komutları yürütür.
compile görevinin tüm bağımlılıkları çalıştırılmışsa compile görevinde tanımlanan komutları yürütür.
dist görevinin tüm bağımlılıkları çalıştırılmışsa dist görevinde tanımlanan komutları yürütür.

Sonuç olarak, dist görevi çalıştırıldığında Ant tarafından yürütülen kod aşağıdaki kabuk komut dosyasına eşdeğerdir:

./createTimestamp.sh
mkdir build/
javac src/* -d build/
mkdir -p dist/lib/
jar cf dist/lib/MyProject-$(date --iso-8601).jar build/*

Söz dizimi kaldırıldığında, derleme dosyası ve derleme komut dosyası aslında pek de farklı değil. Ancak bunu yaparak çok şey kazandık. Diğer dizinlerde yeni derleme dosyaları oluşturabilir ve bunları birbirine bağlayabiliriz. Bu sayede rastgele ve karmaşık yollarla mevcut görevlere dayalı yeni görevler ekleme. Biz ant komut satırı aracına yalnızca tek bir görevin adını iletebilir ve çalıştırılması gereken her şeyi belirler.

Ant, ilk olarak 2000 yılında yayınlanan eski bir yazılımdır. Maven ve Gradle gibi diğer araçlar, geçen yıllar içinde Ant'ı geliştirdi ve harici bağımlıların otomatik yönetimi ve XML içermeyen daha temiz bir söz dizimi gibi özellikler ekleyerek temelde Ant'ın yerini aldı. Ancak bu yeni platformların doğası aynı kalır: mühendislere komut dosyalarını kolayca prensip haline getirilmiş ve modüler bir şekilde yürüttük ve bu görevlerin yürütülmesi için ve yönetmeyi öğreneceksiniz.

Görev tabanlı derleme sistemlerinin karanlık tarafı

Bu araçlar, mühendislerin herhangi bir komut dosyasını görev olarak tanımlamasına olanak tanıdığı için son derece güçlüdür ve hayal edebileceğiniz hemen hemen her şeyi yapmanıza olanak tanır. Ancak bu gücün bazı dezavantajları vardır ve göreve dayalı derleme sistemleri, oluşturma komut dosyaları daha karmaşık hale geldiğinden bunlarla çalışmak zorlaşır. Bu tür sistemlerin sorunu, mühendislere çok fazla, sisteme ise yeterince güç vermesidir. Sistem, komut dosyalarının ne yaptığı hakkında hiçbir fikre sahip olmadığından derleme adımlarını planlama ve yürütme konusunda çok ihtiyatlı olması gerekir. Bu da performansı olumsuz etkiler. Sistem bunun hiçbir şekilde her bir komut dosyasının olması gerekeni yaptığını teyit etmek için daha karmaşıktır ve hata ayıklama gerektiren başka bir unsurdur.

Derleme adımlarını paralelleştirmenin zorluğu

Modern geliştirme iş istasyonları, paralel olarak birkaç derleme adımı yürütebilen birden fazla çekirdeğe sahip olduğundan oldukça güçlüdür. Ama göreve dayalı sistemler görevin yürütülmesi gerektiği gibi görünse de genellikle sahip olacaksınız. A görevinin B ve C görevlerine bağlı olduğunu varsayalım. Çünkü B ve C görevleri birbirlerine bağımlı olmadığı için, bunları aynı anda çalıştırmak güvenli mi? daha hızlı bir şekilde A görevine geçmesini mi sağlayacak? Aynı kaynaklara dokunmuyorlarsa evet. Ama belki hayır. Her iki durumda da izleme için aynı dosyayı aynı anda çalıştırılması bir çakışmaya neden olur. Hayır, çoğu zaman sistem bunu bilebilir, o yüzden bu çatışmaları (nadir bulunan ancak hata ayıklaması çok zor yapı sorunlarına yol açar) veya tüm derlemeyi tek bir işlemde tek bir iş parçacığında çalışacak şekilde sınırlandırır. Bu durum, güçlü bir geliştirici makinesinin büyük bir israfına yol açabilir ve derlemenin birden fazla makineye dağıtılmasını tamamen imkansız kılar.

Artımlı derlemeleri gerçekleştirme zorluğu

İyi bir derleme sistemi, mühendisler makine öğrenimi gibi güvenilir artımlı derlemeler ve küçük bir değişikliğin kod tabanının tamamının yeniden oluşturulmasını gerektirmediğini oluşturalım. Bu, özellikle derleme sistemi yavaşsa ve yukarıda belirtilen nedenlerden dolayı derleme adımlarını paralelleştiremiyorsa önemlidir. Ancak maalesef görev tabanlı derleme sistemleri de bu konuda zorlanıyor. Görevler her şeyi yapabildiğinden, genel olarak bu görevlerin daha önce yapılıp yapılmadığını kontrol etmek mümkün değildir. Birçok görev, bir dizi kaynak dosya alır ve bir derleyici çalıştırarak bir dizi ikili dosya oluşturur. Bu nedenle, temel kaynak dosyalar değişmediyse bu görevlerin yeniden çalıştırılması gerekmez. Ancak ek bilgi olmadan sistem bunu söyleyemez emin olabilirsiniz. Görev, değiştirilmiş olabilecek bir dosya indirir veya her çalıştırmada farklı olabilecek bir zaman damgası yazar. Garanti yeniden çalıştırması gerektiği anlamına gelir. Bazı derleme sistemleri, mühendislerin bir görevin yeniden çalıştırılması gereken koşulları belirtmesine izin vererek artımlı derlemeleri etkinleştirmeye çalışır. Bu bazen uygulanabilir ancak genellikle göründüğünden çok daha karmaşık bir problem. Örneğin, dosyaların doğrudan diğer dosyalar tarafından dahil edilmesine izin veren C++ gibi dillerde, giriş kaynaklarını ayrıştırmadan değişiklikler için izlenmesi gereken dosya grubunun tamamını belirlemek mümkün değildir. Mühendisler çoğu zaman kestirme yollara başvuruyor Bu kısayollar, görev sonucunun belirli bir görev sonucunun kullanılmaması gerektiği halde tekrar kullanılmasıdır. Bu durum sık sık yaşandığında mühendisler yeni bir durum elde etmek için her derlemeden önce temiz derleme yapma alışkanlığı edinir. Bu da ek derlemenin amacını tamamen ortadan kaldırır. Bir görevi ne zaman tekrar çalıştırmanız gerektiğini belirlemek şaşırtıcı derecede kolay değildir ve insanlardan çok makineler tarafından daha iyi işleme alınır.

Komut dosyalarını sürdürme ve hata ayıklama zorluğu

Son olarak, görev tabanlı derleme sistemlerinin zorunlu kıldığı derleme komut dosyalarının kullanımı genellikle zordur. Genellikle daha az inceleme alsalar da derleme komut dosyaları, derlenen sistem gibi koddur ve hataların gizlenmesi için kolay yerlerdir. Aşağıda, göreve dayalı derleme sistemi:

Görev A, belirli bir dosyayı çıktı olarak oluşturmak için görev B'ye bağlıdır. Sahibi B görevi diğer görevlerin buna bağlı olduğunun farkında değildir; bu nedenle, ve farklı bir konum üretebilir. Bu durum, yalnızca bir kullanıcı A görevini çalıştırmaya çalışır ve başarısız olduğunu görür.
Görev A, görev B'ye bağlıdır. Görev B, görev C'ye bağlıdır. Görev C, A görevinin ihtiyaç duyduğu belirli bir dosyayı çıkış olarak üretir. B görevinin sahibi artık C görevine bağlı olmadığına karar verir. Bu da B görevi C görevini hiç önemsememesine rağmen A görevi başarısız olur.
Yeni bir görevin geliştiricisi yanlışlıkla o görev hakkında bir aracın konumu veya aracın değeri gibi değişkenlerine odaklanacağız. Görev, geliştiricinin makinesinde çalışıyor ancak başka bir geliştirici denediğinde başarısız oluyor.
Görev, internetten dosya indirme veya derlemeye zaman damgası ekleme gibi kesin olmayan bir bileşen içerir. Artık kullanıcılar derlemeyi her çalıştırdığında farklı sonuçlar elde ediyor. Bu da mühendislerin her zaman birbirlerinin hatalarını veya otomatik derleme sisteminde oluşan hataları yeniden oluşturup düzeltmelerini zorlaştırıyor.
Birden çok bağımlılığı olan görevler yarışma koşulları oluşturabilir. Görev A hem görev B'ye hem de görev C'ye bağlıysa ve görev B ile C aynı dosyayı değiştiriyorsa görev A, B ve C görevlerinden hangisinin önce bittiğine bağlı olarak farklı bir sonuç alır.

Burada açıklanan görev tabanlı çerçevede bu performans, doğruluk veya sürdürülebilirlik sorunlarını çözmenin genel bir yolu yoktur. Mühendisler derleme sırasında çalıştırılacak rastgele kod yazabildikleri sürece sistem, derlemeleri her zaman hızlı ve doğru bir şekilde çalıştırabilecek yeterli bilgiye sahip olamaz. Sorunu çözmek için gücümüzden yararlanmamız gerekiyor. yeniden vererek sistemi yeniden oluşturup değil, eserler üretmekten ibarettir.

Bu yaklaşım, Blaze gibi yapı tabanlı derleme sistemlerinin oluşturulmasını sağladı ve Bazel.