CMake "proje" yönergesinin doğru kullanımı nedir?

Question

Birkaç düzine kitaplık ve çeşitli çalıştırılabilir dosyalar geliştiren büyük ish kod örneğim var.

Kod tabanı hiyerarşik olarak ayrıştırılır ve kütüphaneler hemen hemen her düzeyde oluşturulur.

Her kitaplığı oluşturmak için her bir dizine gittim ve bir CMakeLists.txt dosyası yerleştirdim.

Her CMakeLists.txt dosyasında "project (xxx)" yönergesini kullandım. Bu, benim için mantıklı kullanımı yaptığım PROJECT_NAME, PROJECT_SOURCE_DIR ve PROJECT_BINARY_DIR değişkenlerini tanımladı. Bununla birlikte, takımdan biri bu yaklaşımı hiç beğenmedi, çünkü bunu yapan başka herhangi bir gerçek dünya örneği bulamadı. Çoğu zaman KitWare örneklerini bu yaklaşımı kullanmıyor diye belirtiyor ve bu yüzden de yapmamalıyız.

Savunmaktan yana olduğu alternatif yaklaşım, bu değişkenleri "maket" in size verdiği gibi görünen her makefile yerleştirmektir.

Gerçekten onun noktasını göremiyorum ve onu başka türlü ikna etmede çok az adım atıyorum. Proje direktifini kullanmanın olumsuz taraflarına bu şekilde ışık tutabilir.

Kendimi kolektif bilgeliğine atarım?

Answer 1

İlk olarak, <projectName>_BINARY_DIR ve <projectName>_SOURCE_DIR'u kullanmanıza olanak tanır, ancak bu ana avantaj değildir. CMake'e proje adı verirseniz, alt dizinlerin her biri için kendi dizinlerindeki yapı hedeflerini oluşturur. Bu, GNU Make, Eclipse CDT, XCode veya desteklenen diğer jeneratörlerden herhangi birini kullanıp kullanmadığınızı, alt projeleri tek tek oluşturabileceğiniz anlamına gelir. Örneğin, GNU ile her bir alt projenin kendi dizininden kendi tam inşa sistemine sahip olmasını sağlayın.

Geçerli proje adına PROJECT_NAME ve kök proje adı aracılığıyla CMAKE_PROJECT_NAME'a erişebilirsiniz.

Düzenleme: Projenin yapılıp yapılmadığına göre, aşağıdaki herhangi bir yapı hedefi için standart CMake davranışı olacağını fark ettim. Genel bilgi için burada kalacağım ama şu cevaba uygun değil:

Bir C++ kitaplığım varsayalım ve üç tane ikili yürütülebilir dosya oluşturabilirim; Main ve tests/test1 ve examples/ex1. Ben TÜM hedef ile CMake denen dizinde, make ex1 çalıştırın ya da dizinini examples/ olarak değiştirebilir ve bu dizinden make örneklerini oluşturabilirsiniz. Bu, dizin yapısında başka bir yerde olsalar bile tüm bağımlı projeleri ve kitaplıkları oluşturacaklardır, ancak Main veya tests/test1'u veya examples/ex1'a bağlı oldukları herhangi bir kitaplığı oluşturmayacaktır. Daha sonra ana dizinden çalıştırırsam, kaynaklarının değişmediği sürece examples/ex1'un bağlı olduğu kitaplıkların hiçbirini yeniden oluşturmaz.

Answer 2

Kitaplıklar gerçekten bağımsız projelerse, project komutunu kullanmak mantıklıdır. Ancak eğer olmasalardı, ben sadece onları CmakeLists.txt kökünüzde alt dizinler olarak eklerim. Şu anda işlenmekte olan dizinleri bilmeniz gerekiyorsa, CMAKE_CURRENT_SOURCE_DIR ve CMAKE_CURRENT_BINARY_DIR değişkenlerini kullanabilirsiniz.

Answer 3

Bugün tam olarak bunun iyi bir örneğini buldum: Doxygen dokümantasyonunu eklemek.

Kişisel C++ projelerimi oluşturmak için CMake (ve Ninja) kullanıyorum. Oldukça eksiksiz ve belgelenmemiş çabalarıma bir miktar Doxygen belgesi eklemeye karar verdim. Ayrıca, diğer projelere de eklemenin, olabildiğince genel olarak nasıl yapılacağını anladığım kadarıyla düzgün olacağını düşündüm.

Başlamak için standart bir Doxygen şablonu oluşturdum ve yeniden adlandırdım.

cd my_projects/projectx 
doxygen -g Doxyfile 
mv Doxyfile Doxyfile.in 

.in uzantısına dikkat edin. Muhtemelen gerekli değil ama geleneksel olarak, eğer doğru anlarsam.

Daha sonra, CMakeLists.txt dosyasında, hedeflerimi tanımlamadan hemen önce aşağıdaki kod bloğunu ekledim (önemli olup olmadığından emin olmamakla birlikte, CMake bazen belirli komutların sırasına göre yanık oluyor).

FIND_PACKAGE(Doxygen) 
IF("${DOXYGEN_FOUND}" MATCHES "^YES$") 
    CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in 
        ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile 
        @ONLY) 
    ADD_CUSTOM_TARGET( doc ALL 
         COMMAND ${DOXYGEN_EXECUTABLE} 
         ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile 
         WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} 
         COMMENT "Doxygenating..." 
         VERBATIM) 
ENDIF() 

Bu, doc adında yeni bir hedef oluşturur. ALL belirtmek varsayılan "all" hedefine ekler, ancak bu isteğe bağlıdır. @ONLY belirtmek, "$ {variable}" türündeki değişkenlerin CONFIGURE_FILE, sadece "@ variable @" türleriyle genişletilmemesini sağlar. Biraz kafa karıştırıcı (bana en azından), CMAKE_CURRENT_SOURCE_DIR, proje dizini ve yapı dizinine CMAKE_CURRENT_BINARY_DIR başvuruyor gibi görünüyor.

Son olarak, bu noktada PROJECT_NAME ve diğerlerinin geldiği yer, Doxyfile.in dosyasını düzenledim.

Bu

benim yeni Doxyfile.in başlangıcıdır:

DOXYFILE_ENCODING  = UTF-8 
PROJECT_NAME   = "@PROJECT_NAME@" 
PROJECT_NUMBER   = @PROJECT_VERSION_TWEAK@ 
PROJECT_BRIEF   = 
PROJECT_LOGO   = @CMAKE_CURRENT_SOURCE_DIR@/res/doc_logo-200x55.png 
OUTPUT_DIRECTORY  = @CMAKE_CURRENT_SOURCE_DIR@/doc 

Sen fikir, bence. Bu tamamen jenerikleştirildikten sonra (bu bir sözcük mü?) Diğer projelerime kopyalayabilirim ve kodumu etiketlediğim sürece her yerde güzel belgelerim olur.

Uyarı PROJECT_BRIEF belirtilmemiş. Bunu bitirmedim ve düşünmem gereken birkaç boşluk var. Örneğin, PROJECT_VERSION_TWEAK henüz bir şey içermiyor. Orada yapı numaramı almanın bir yolunu bulmalıyım.