OpenJDK İnşa(Building) Part14

OpenJDK build ile ilgili önceki yazılarıma aşağıdaki linklerden ulaşabilirsiniz.

OpenJDK serisinin 1.bölümü için Link
OpenJDK serisinin 2.bölümü için Link
OpenJDK serisinin 3.bölümü için Link
OpenJDK serisinin 4.bölümü için Link
OpenJDK serisinin 5.bölümü için Link
OpenJDK serisinin 6.bölümü için Link
OpenJDK serisinin 7.bölümü için Link
OpenJDK serisinin 8.bölümü için Link
OpenJDK serisinin 9.bölümü için Link
OpenJDK serisinin 10.bölümü için Link
OpenJDK serisinin 11.bölümü için Link
OpenJDK serisinin 12.bölümü için Link
OpenJDK serisinin 13.bölümü için Link

Derleme Sistemini Anlamak

Bu bölümde Derleme sistemi hakkında ayrıntılı incelemelere yer verilecektir.

Konfigürasyonlar
Serinin başlarında incelediğimiz “configure” yapısının,derleme süreci için yaptığı hazırlıkları biliyoruz.
Derleme başlarken,derleme sistemi bir veya daha fazla konfigürasyon bulmayı bekler.Bunlar teknik olarak build alt dizinindeki bir alt dizinde “spec.gmk” tarafından tanımlanır. Bu dosya(spec.gmk) “configure” tarafından üretilir ve prensip olarak konfigürasyonu içerir(doğrudan veya spec.gmk tarafından dahil edilen dosyalar ile).

Aslında make’i SPEC komutu ile kullanarak ve devamında “spec.gmk” dosyasına işaret ederek bir konfigürasyon seçebilirsiniz.
Bunu aşağıdaki komutla yapabilirsiniz:

make SPEC=$BUILD/spec.gmk

Bir kullanıcı olarak “make”’i bu şekilde çağırmak önerilmese de,aslında build sistemi tarafından bu şekilde kullanıldığını bilmemizde fayda var.

Çıktı(Output) Yapısı
Proje konfigüre edilirken,derleme çıktıları(output) için bazı hazırlıklar yapılır.Bu önemli hazırlıklar,konfigürasyon tamamlandığında “build/<konfigürasyon adı>” şeklinde bir dizin yapısıyla son bulur. Konfigürasyon adıyla biten dizin içerisinde aşağıdaki önemli dizinler(klasörler) yer alır.

 buildtools/
 configure-support/
 hotspot/
 images/
 jdk/
 make-support/
 support/
 test-results/
 test-support/

Bu dizinlerin her birinin görevi ve içeriği aşağıdaki gibidir:

• images: Bu dizin make’i “image” ile kullandığımızda “*-image” çıktılarının yer aldığı dizindir.Örneğin aşağıdaki komutun çıktısı “images/jdk” içinde tamamlanır.

make jdk-image

• jdk: Derlenmiş JDK imaj çıktısı bu dizinde yer alacaktır.
  “make jdk” komutundan sonra,aşağıdaki komut yardımıyla yeni oluşturulmuş JDK’yı çalıştırabilirsiniz:

$BUILD/jdk/bin/java

• test-results: Bu dizin,çalıştırılan testlerin sonuçlarını içerir.
• support: Bu dizin,build sırasında ihtiyaç doyulan ara dosyaları içerir.
  Örneğin: Kaynak kod dosyaları,sınıf ve object dosyalarını içerir.
  Bu dizin(support) içinde dikkate değer bazı dizinler yer alır. Bunlardan biri üretilmiş kaynak kodunu barındıran “gensrc”’dir.
  Bir diğeri ise modül dosyaları içeren “modules_*” dizinidir.
• buildtools: Bu dizin,derleme platformu için derlenmiş araçların(tools) tutulduğu alandır.
• hotspot: Bu dizin,hotspot’u derlerken ihtiyaç duyulan ara dosyaların tutulduğu alandır.
• configure-support, make-support Ve test-support: Dizinlerin isimlerinden de anlaşıldığı gibi;derleme sistemi tarafından ihtiyaç duyulan “configure”,”make” ve “test” için ihtiyaç duyulan dosyaların tutulduğu alandır.

Fixpath
Windows’ta çalışırken,Unix/Linux kök dosya yapısına sahip araç-gereç yolları(path) genellikle uyumsuzluklara sebep olur.
Çünkü Unix/Linux’da kök dosya yolu “/home/foo” şeklindedir.Ancak buna karşılık olarak Windows’da ise “C:\User\foo” şeklindedir.

JDK yapısında ve build edilirken,her zaman unix/linux yapısı kullanılır.
Ancak unix kök dosya yolundan anlamayan ortamlarda çalışırken,bu yolları dönüştürerek ilgili sistemin anlayabileceği hale getirmemiz gerek.
Bu dönüştürmeyi yapan araç ise “fixpath”’dır. Dolayısıyla bu dönüştürme aracı,Windows ortamında çalışanların ihtiyaç duyacağı önemli bir araçtır.
Windows ortamında çalışıyorsanız bu aracı(tool) önceki bölümlerde anlatıldığı gibi konumlandırmanız gerekir.
Böylece “configure” sürecinde otomatik olarak kullanılacaktır.

Hata Ayıklama Sembolleri
Native kütüphaneler ve çalıştırılabilir dosyalar kendileriyle ilişkili hata ayıklama sembollerine sahip olabilir.Bunun nasıl çalıştığı büyük ölçüde platforma bağlıdır. Ancak hata ayıklama sembolü bilgilerinin çok fazla disk alanı gerektirmesi yaygın bir sorun olarak görülüyor.Ancak bunlara son kullanıcı tarafından nadiren ihtiyaç duyuluyor.

JDK,hata ayıklama sembollerinin nasıl işleneceği konusunda farklı yöntemleri destekler.Kullanılan yöntemler aşağıdaki komutla seçilir:

--with-native-debug-symbols

Ve mevcut yöntemler ise şunlardır: none, internal, external, zipped.Aşağıda bu yöntemlerin açıklamalarına yer verilmiştir.

• none: Derleme esnasında hata ayıklama sembollerinin oluşturulmayacağı anlamına gelir.
• internal: Derleme sırasında hata ayıklama sembollerinin üretileceği ve oluşturulan ikili(binary) dosyada depolanacağı anlamına gelir.
• external: Derleme sırasında hata ayıklama sembollerinin üretileceği ve derlemeden sonra ayrı bir “.debuginfo” dosyasına taşınacağı anlamına gelir. Bu daha önceleri FDS(Full Debug Sysmbols) olarak biliniyordu.
• zipped: Bu “external”’e benzerdir. Tek farkı “.debuginfo” dosyasını “.diz” olarak sıkıştırır.

JDK’yı nihayi amaçlı,yani dağıtmak içi derlerken,zipped yöntemi iyi bir çözümdür. Öte yandan hata ayıklamayı kolaylaştırdığı için “internal” seçeneği geliştiriciler tarafından kullanılması uygundur.Fakat son kullanıcı için derlerken “internal” seçeneği kaldırılmalıdır.Bu seçenek son kullanıcı için uygun değildir ve dolayısıyla gereksizdir.

Autoconf Ayrıntıları
“configure” betiği “autoconf” çerçevesine dayanır.
Ancak bazı ayrıntılarda normal bir “autoconf”,”configure” betiğinden farklıdır.
JDK’nın en üst düzey dizinindeki configure”betiği,”make/autoconf/configure”
öğesini çağıran basit bir sarmalayıcıdır.Bu da “.build/generated-configure.sh” olarak çalıştırılabilir konfigürasyon betiğini oluşturmak için “autoconf”’u çalıştıracaktır. Çalıştırılabilir betiğin oluşturulmasından sorumlu olmanın yanı sıra,”configure” betiği normal “autoconf” çerçevesinde kolayca ifade edilemeyen işlevsellik de sağlar.

Build sistemi “autoconf” kaynak dosyalarının değişip değişmediğini tespit edecek ve gerekirse oluşturulan komut dosyasının yeniden oluşturulmasını tetikleyecektir.Ayrıca bu işlemi aşağıdaki komut ile manuel olarka da yapabilirsiniz.

bash configure autogen

JDK’nın önceki sürümlerinde,oluşturulan komut dosyası “make/autoconf/generated-configure.sh” içinde kontrol ediliyordu.
Ama artık böyle çalışmıyor.

Bu bölümle birlikte “OpenJDK Build” serisini tamamlıyoruz.
OpenJDK ile ilgili sonraki yazılarımda,Test Çalıştırma,Kaynak kod ekleme/Geliştirme,Algoritma,Analiz ve diğer JDK geliştirmeyle ilgili konuları işleyeceğiz.

-end of