C basit bir vektör sınıfı yaparak başlamak istiyorum karar verdim genel olarak programlamaya yeni duyuyorum . Ancak iyi alışkanlıklar için, benim iş akışı daha sonra değiştirmek için çabalamak yerine, baştan almak istiyorum.

Ben şu anda sadece iki dosya vector3.hpp vector3.cpp var. Bu proje yavaş yavaş başlamak için büyümek (yapmak çok daha genel bir Lineer Cebir kitaplığı) gibi olur daha tanıdık olan her şey, çok isterdim, kabul etmesi halinde "standart" proje düzeni için hayat daha kolay daha sonra. Etrafında hes ve cpp dosyalarını düzenlemek için iki yol buldum baktıktan sonra, ilk olmak

project
└── src
    ├── vector3.hpp
    └── vector3.cpp

ve ikinci olmak

project
├── inc
│   └── project
│       └── vector3.hpp
└── src
    └── vector3.cpp

Hangisini ve neden önerirsiniz?

İkincisi oldukça kolay gibi görünüyor, benim birim kodu test etmek için Google C Test Çerçevesi kullanmak istiyorum. Benim kod ile donatılacak, inc/gtest contrib/gtest bir klasörde örneğin önerirsin? Birlikte eğer, fuse_gtest_files.py komut numarasını veya dosyaları azaltmak için kullanarak, ya da terk önerirsin? Birlikte değil bu bağımlılık nasıl işlenir?

Test yazmak için geldiğinde, bunlar genellikle nasıl düzenlenir? Birlikte kolayca çalıştırılabilir diye düşünerek bir cpp sınıf (örneğintest_vector3.cpp) ama hepsi tek bir ikili derlenmiş her biri için bir dosya var mı?

Gtest kütüphane genellikle cmake kullanarak inşa etmek ve yapmak olduğu için, benim projem de bu şekilde yapılmış olması mantıklı olur diye düşünüyordum? Eğer aşağıdaki proje düzeni kullanmaya karar verdim:

├── CMakeLists.txt
├── contrib
│   └── gtest
│       ├── gtest-all.cc
│       └── gtest.h
├── docs
│   └── Doxyfile
├── inc
│   └── project
│       └── vector3.cpp
├── src
│   └── vector3.cpp
└── test
    └── test_vector3.cpp

Nasıl CMakeLists.txt ya kütüphaneye ya da kütüphane ve testleri inşa edebilir, bu yüzden bakmak gerekir? Ayrıca build bin Dizin tam bir proje gördüm. İnşa dizini içinde olmasına ve dosyalar için bin dizinine taşındı oluşturur? Testler ve kütüphane için ikili aynı yerde yaşıyor ki? Yoksa bu yapı için daha fazla anlam ifade aşağıdaki gibi olur

test
├── bin
├── build
└── src
    └── test_vector3.cpp

Ayrıca doxygen kodumu belge için kullanmak istiyorum. Bu otomatik olarak cmake ile çalıştırmak ve yapmak için almak mümkün mü?

Bu kadar çok soru için özür dilerim, ama tatmin edici bir soru bu tür cevap C ile ilgili bir kitap bulamadım.

C sistemleri siyah bir sanat biraz ve bu büyük projeyi şaşırtıcı değil bu yüzden bulabilirsiniz daha garip bir sürü şeyler sorulara gel. Soruların üzerinden tek tek yürüyüş ve bazı genel şeyler bina C kitaplıkları ile ilgili söz etmeye çalışacağım.

Başlıkları ve cpp ayıran dizinlere dosyaları. Bu sadece temel halinde kullanılması gereken bir bileşeni oluşturuyorsanız gerçek bir uygulama yerine bir kütüphane gibi. Senin başlıkları var kullanıcılar ne teklif ile etkileşim için temel ve olmalıdır yüklü. Bu kimse ister bir alt dizininde olması demek." başlıkları üst düzey /usr/include/ biten) çok sayıda ve başlıkları böyle bir kurulum ile kendilerini dahil etmek gerekir.

└── prj
 ├── include
 │   └── prj
 │       ├── header2.h
 │       └── header.h
 └── src
     └── x.cpp

yollar vardır ve kolay kullanabilirsiniz, çünkü bu iyi çalışıyor, hedefler yüklemek için genelleştirme.

Donatılacak bağımlılıklar: bu büyük ölçüde bağlıdır bence ve bağımlılıkları bulun yapılandırmak için inşa sistemi ve nasıl bağımlı tek bir sürüm kodu. Ayrıca nasıl bağlıdır mümkün kullanıcıların ne kadar kolay bağımlılık onların üzerine yüklemek için platform. CMake Google için find_package bir komut dosyası ile birlikte gelir Test. Bu işleri çok daha kolay hale getirir. Sadece paketleme ile giderdim gerekli zaman ve aksi takdirde kaçının.

Nasıl:-kaynak oluşturur Kaçının. CMake kaynak-yapılar yapar kolay ve hayat daha kolay olur.

Ayrıca CTest sistem testleri çalıştırmak için kullanmak istiyorum sanırım ( ayrıca build-GTest için destek) ile birlikte gelir. Önemli bir karar düzen ve test organizasyonu olacak dizini: seninle sonuna kadar projeleri? Yani, ihtiyacın biraz daha CMakeLists kurarken çalışmak ve alt dizinlerin içine alt bölünmüş gerektiğini, her ile include src dosyaları kendi. Hatta belki de kendi doxygen çalışır ve (birden fazla doxygen projeleri birleştirmek mümkün, ama kolay değil çıkışlar ya da çok).

Böyle bir şey ile sona erecek:

└── prj
    ├── CMakeLists.txt <-- (1)
    ├── include
    │   └── prj
    │       ├── header2.hpp
    │       └── header.hpp
    ├── src
    │   ├── CMakeLists.txt <-- (2)
    │   └── x.cpp
    └── test
        ├── CMakeLists.txt <-- (3)
        ├── data
        │   └── testdata.yyy
        └── testcase.cpp

nerede

• (1) yapılandırır bağımlılıkları, platform özellikleri ve çıkış yolları
• (2) yapılandırır kütüphane yapacağız
• (3) yapılandırır testi çalıştırılabilir ve test durumlarda

Davasındaki alt bileşenler başka bir hiyerarşi ekleme önermek ve her yukarıdaki ağaç alt proje kullanırdım. İşlerin alt bileşenleri arama ve yapılandırma bağımlılıkları ise üst düzey bunu yaparsanız o karar vermeniz gerekir, çünkü zor olsun o zaman. Bu-durum-durum bazında karar verilmelidir.

Yapılandırma ile dans gitmek için yönetilen Sonra Doxygen: doxygen, önemsiz CMake add_custom_command eklemek için kullanın doktor hedef.

Bu benim proje sonunda ve çok benzer bazı projeler gördüm, ama tabii ki bu bir tedavi.

EkBir noktada config.hppoluşturmak isteyeceksiniz bu sürüm bir sürüm ve belki de define bir tanımlama içeren dosya tanımlayıcı (karma Gıt veya SVN Revizyon numarası) kontrol. CMake vardır bu bilgileri bulmak ve oluşturmak için otomatikleştirme modülleri dosyaları. CMake configure_file bir değişken değiştirmek için kullanabilirsiniz değişkenleri ile şablon dosyası CMakeLists.txt içinde tanımlanmış.

Ayrıca ihracat için tanımlamak gerekir kütüphaneler Daire Derleyiciler arasındaki fark, örneğin __declspec MSVC hemen ve visibility GCC/çınlama bağlıyor.