Merhaba sevgili yazılımperver dostlarım,

Daha önce de bahsettiğim gibi uzun bir süredir uEngine4 reposunun hem Windows hem Linux için kullanılabilir hale getirmeye yönelik planlarım mevcuttu. Ayrıca, bir kaç yazımda CMake betikleri ile ilgili de bir kaç güncelleme yapmayı planlıyordum. Nihayet bu güncellemeleri tamamladım ve artık uEngine4’ü hem Windows hem de Linux için kullanabileceksiniz. Bu bağlamda yapılan güncellemeleri “pre-update” branchi içerisinden takip edebilirsiniz. İlgili repoya aşağıdaki adresten ulaşabilirsiniz:

https://github.com/yazilimperver/uEngine4

Gelelim bu bağlamda yapılan güncellemelere.

Dizin Yapısının Basitleştirilmesi

Daha önce her bir dizin için oluşturulan projeler yerine temel kabiliyetleri içerecek daha az sayıda projeler oluşturmak ve dizin yapısının basitleştirilmesi.

• Bu bağlamda basic_engine, infra, gis ve gl altındaki projeleri ortadan kaldırarak, ilgili projeler: “basic_engine“, “infra“, “gis” ve “gl” projeleri altında toplanmıştır ve diğer CMake dosyaları da silinmiştir,
• /binary, /code/src  dizinleri silinmiş, kaynak kodlar /code dizini altına alınmıştır,
• Visual Studio 2022 proje dosyalarının silinmesi (/code/project),
• apps dizini altında örnek projeler tutulmaya devam edilmiştir.

Sonuç olarak aşağıdaki gibi bir dizin yapımız oldu:

CMake Betik Güncellemeleri

CMake betiklerini sadeleştirmek ve diğer güncellemeler:

• CMake minimum sürümü 3.23‘e yükseltildi. Bunun temel sebebi, preset ve diğer bir takım güncel kabiliyetleri kullanabilmek,
• Daha önce CMake şablonuna ilişkin yazımda sizler ile paylaştığım, CMake şablonunu, uEngine4 için de kullanılır hale getirilmiştir ve bu bağlamda da preset’ler kullanılabilir. Presetlere ilişkin detaylı bilgilere ilgili yazımdan ulaşabilirsiniz,
• Yaptığım önemli değişikliklerden birisi, projeler (target)’lar için kullanılacak olan dosyaları direk CMakeLists.txt içerisine değil de ilgili .cmake dosyaları içerisine ekledim (Ör. /code/infra/cmake/…_files.cmake). Açıkçası bu buna, cmake betik dosyasını sadeleştirmesi açısından daha kullanışlı geldi,
• İlgili kütüphanelere özgü bağımlılıkların PRIVATE ile, bunun yanında bu kütüphaneleri kullanacak projelerin de ihtiyaç duyacağı kütüphaneler PUBLIC olarak eklenmiştir,
• Gereksiz ya da tekrarlı satırlar çıkarılmıştır,
• Üçüncü parti kütüphaneler mümkün olduğunca, FindPackage ve target’lar üzerinden kullanılır hale getirilmiştir,
• Eskiden proje/dizin içerisinde bulunan kaynak kodlar “source_group” olarak eklenmiştir,
• Tepe CMakeLists.txt içerisi de elden geçirildi. Bu bağlamda cmake modül ve 3. parti kütüphane dizinleri betik içerisine eklenmiştir. Bu dosyalar da “code/cmake” altında toplanmıştır. Buradaki dosyalara ilerleyen satırlarda ayrı bir parantez açıyor olacağım.

CMake betiklerinin kullanıma alınması,

• Projeniz büyükçe ve target sayınız arttıkça, CMake betiklerinde de ortaklama ihtiyacını hissediyorsunuz. Bunun için de aslında kullanılabilecek yegane yöntemlerden birisi de .cmake uzantılı betiklerin kullanılması. Ben de bu bağlamda aşağıdaki dosyaları oluşturdum, sizler de ihtiyaca göre benzerlerini oluşturabilirsiniz:
  • TargetOSSetup.cmake: İşletim sistemine ve build tipine göre oluşturulacak olan target’ların isimlendirilmesi ve işletime sistemine yönelik ayarlar,
  • OpenGLOptions.cmake: İşletim sistemine göre ortak OpenGL kütüphanelerine yönelik bir takım değişkenlerin ayarlanması,
  • InsourceGuard.cmake: CMake ile ilgili oluşturma dosyalarının aynı dizinde oluşturulmasına karşın önlem içeren dosya,
  • FolderOptions.cmake: Projede kullanılan ortak dizinlerin belirlendiği dosya,
  • CompilerOptions.cmake: İşletim sistemine ve araca göre derleme ve benzeri parametreleri verebileceğiniz dosya,
  • StandardOptions.cmake: Yazılımı oluştururken sunulan opsiyonlar (bunlar ayrıca CMake UI’ında da görülebilir),
  • CommonFunctions.cmake: Bağımlılıkların kopyalanmasına yönelik fonksiyonları içeren dosyadır.
• Yukarıdakiler yanında daha önce de bahsettiğim gibi, proje kaynak dosyalarını da direk CMake betikleri içerisine eklemek yerine, ayrı dosyalarda tutmaya başladım.

Uygulamalara ilişkin bağımlılıkların, örnek uygulamaların yanına otomatik taşınması da yine CMake betikleri aracılığı ile yapılan güncellemelerden birisi. Şöyle ki:

• Örnek uygulamalarda kullanılan sd_application_configuration.json konfigürasyon dosyasının kopyalanması,
• Ayrıca, Windows tarafında baş ağrısına sebep olan .dll’lerin el ile kopyalanmasına yönelik de bir güncelleme yaptım. Örnek uygulamalar için, ortak olarak kullanılacak olan .dll’ler konfigürasyon zamanında, ilgili dizinlere artık otomatik olarak kopyalanıyor,
• Asset’ler için özel bir şey yapmadım, zaten assetleri kullanan örnek uygulamalara baktığınızda CMake’in de yardımıyla ayrı bir başlık dosyası oluşturarak, asset dizin yolları yine konfigürasyon zamanında oluşturulmakta.

Üçüncü Parti Bileşenlerin Kullanımı

3. parti kütüphanelerin kullanılmasına yönelik de yeni yöntemleri proje dahil ettim. Şimdilik hepsi duruyor ama ileride muhtemelen seçilen yöntemlerle ilerliyor olacağım:

• Daha önce üçüncü parti kütüphaneleri eklerken komut satırından verilen dizin ve ana CMakeLists.txt içerisindeki dizinler üzerinden yapıyorduk. Artık bunlar daha çok cmake modül ve paketi olarak eklenmekte,
• Zaten indirilmiş üçüncü parti kütüphaneler yanında, diğer kullanımlara örnekler eklenmiştir. Bunları şöyle sıralayabiliriz:
  • add_subdirectory ile direk ekleyerek oluşturma. google-test buna örnek. Aslında üçüncü parti bir bileşenden ziyade yazılımın bir parçası haline gelir. Çok değiştirilmeyecek bileşenler için bu yöntem izlenebilir,
  • CMake submodule ile ilgili reponun eklenmesi. glm kütüphanesini bu şekilde ekledik. Üçüncü parti kütüphanelerin güncel hallerini sürekli kullanmayı istemeniz durumunda bu seçeneği kullanabilirsiniz fakat ilgili submodule yazımda da bahsettiğim gibi dikkat etmeniz gereken noktalar var (güncelleme ve ilk olarak dosyaları alma),
  • FetchContent kullanımı, son zamanlarda yaygın olarak kullanılan yöntemlerden birisi, ana CMake betiği içerisinde yorumlu olarak bıraktım. Spdlog bu şekilde indirilebilir. Temelde internetten ilgili reponun indirilerek, projelerde target olarak kullanılmasına olanak sağlamakta. Detaylı malumatlar betik içerisinde mevcut,
  • Son olarak da ExternalProject kullanımı. Bu yöntem de FetchContent’te benzese de, aralarında temel bir fark bulunmakta. FetchContent, ilgili bağımlılıkları konfigürasyon zamanında indirir ve kullanıma sunar. ExternalProject ise bunu oluşturma zamanında yapar. Açıkçası normal şartlarda, FetchContent tercih edilebilir. Kaynaklara buna yönelik bir iki sayfa ekliyorum.

Sonuç

Gördüğünüz gibi oldukça kapsamlı bir güncelleme oldu. Bundan sonra da inşallah uEngine4’ü yazılarımda daha çok kullanıyor olacağım, örnekler için daha çok başvuruyor olacağız. Sizler de gerek windows gerekse linux için görsel uygulamalarınızda, uEngine4’ü rahatlıkla kullanabilirsiniz.

Sizler ile paylaşacağım araçları da ilk olarak uEngine4 üzerinde deniyor olacağım 🙂 Bunlardan ilki de CCache olacak. Aslında bakarsanız buna yönelik betikleri eklemiş bulunuyorum ama detayları sonraki yazımda değiniyor olacağım. İlgili yazı ile birlikte, yazılım oluşturma sürelerinizi kısaltacak araçlara yönelik bir yazı dizisine başlıyor olacağız. Bu yazıma kadar kendinize çok iyi bakın, bol kodlu günler.

Kaynaklar

https://www.scivision.dev/cmake-fetchcontent-vs-external-project/

https://medium.com/analytics-vidhya/c-dependency-management-with-cmakes-fetchcontent-4ceca4693a5d