Build-System

[fat-lobyte]

Ich bin dafür, dass der BIN und der SOURCE Baum streng voneinander getrennt sind. Dadurch ist die Übersicht besser und man kann ganz einfach neu bauen, indem man BIN löscht.
Also alles, von der Executable bis zu den Makefiles getrennt von der Source

Da hat jemand CMake nicht so ganz verstanden

Das kannst du ganz unabhängig davon machen, wie das Build System aufgebaut ist. Mach irgendwo einen Ordner: dedupe_build

Code: Alles auswählen

mkdir /irgendwo/dedupe_build
cd /irgendwo/dedupe_build
cmake /wo/der/source/liegt/dedupe
make

Das Projekt wird jetzt schon getrennt vom Source gebaut, also /wo/der/source/liegt/dedupe bleibt unverändert, alle Dateien werden in /irgendwo/dedupe_build gebaut.
Die Frage ist: WO in /irgendwo/dedupe_build wollt ihr die Executables haben? in /irgendwo/dedupe_build/bin? oder in /irgendwo/dedupe_build?

Mein Vorschlag wäre dem zu entsprechen: src, obj, bin.

Das soll heißen, alle Dateien die zurzeit in $PROJECT_ROOT liegen, kommen nach $PROJECT_ROOT/src?
$PROJECT_ROOT/bin wäre in Ordnung, allerdings bin ich gegen $PROJECT_ROOT/obj, aus dem einfachen Grund dass jeder selbst entscheiden kann wo er sein Projekt bauen will. CMake erlaubt out-of-source builds, und diese sind auch zu bevorzugen. Ich mach immer das:

Code: Alles auswählen

mkdir $PROJECT_ROOT/build
cd $PROJECT_ROOT/build
cmake ..
make

Sollte sich jemand für in-source builds entscheiden (Sourceverzeichnis = Bauverzeichnis) kann ich schon was dazuhacken, dass die Dateien standardmäßig in build/ erstellt werden.

Theoretisch kann man noch Header und Src trennen, dafür konnte ich mich bisher allerdings nicht begeistern.

Ich glaube das ist für den Fall, dass man Bibliotheken programmiert. Da kommen dann die Header in den include/ Ordner, allerdings nur diejenigen, die "exportiert", also von Benutzern der Bibliothek gebraucht werden. Interne Header bleiben in src/. (So will es der Brauch, glaube ich )

[Bebu]

Ich hätte eine Anfrage für unser CMake Spezialisten. Könntet ihr bitte eine Möglichkeit einbauen, das sowohl ein Debug, als auch ein Releasetarget gebaut werden kann? Release ist noch nicht so wichtig, für Debug wären vor allem Wall-Flag, Debug Flag (ich glaube -g) und das weglassen jeder Optimierung (-O0 ? ) interessant. Ist das machbar?

[fat-lobyte]

Ich hätte eine Anfrage für unser CMake Spezialisten. Könntet ihr bitte eine Möglichkeit einbauen, das sowohl ein Debug, als auch ein Releasetarget gebaut werden kann? Release ist noch nicht so wichtig, für Debug wären vor allem Wall-Flag, Debug Flag (ich glaube -g) und das weglassen jeder Optimierung (-O0 ? ) interessant. Ist das machbar?

Das ist machbar, und zwar ohne Änderungen. Dazu müsst ihr nur ein Flag per Kommandozeile übergeben:

Für Debug Build: (ohne optimierung, mit debug symbolen)

Code: Alles auswählen

cmake -DCMAKE_BUILD_TYPE=Debug /pfad/zum/source

Für Release Build: (mit optimierung, ohne debug symbolen)

Code: Alles auswählen

cmake -DCMAKE_BUILD_TYPE=Release /pfad/zum/source

Achtung, die groß-klein-Schreibung muss genau eingehalten werden. CMake kennt nur "Release" und "Debug", nicht "debug","release", "DEBUG" oder "RELEASE". Seltsam, ist aber so.

Wie ich gerade festgestellt habe gibts noch nen "normalen" build, also ohne optimierung und ohne debugsymbole. Das wäre ohne Flag.


Was ich aber anbieten kann, wäre "Debug" als Standardeinstellung dazuzunehmen. Gewünscht?

[Bebu]

Von mir aus schon, wir sind ja schließlich noch meilenweit von einem Release entfernt

[fat-lobyte]

wie sehen das andere Entwickler?

[Xin]

Aus Sicht einer Entwicklungsabteilung ist der Release wohl eher die Ausnahme.

[fat-lobyte]

Was ich aber anbieten kann, wäre "Debug" als Standardeinstellung dazuzunehmen. Gewünscht?

Asche auf mein Haupt
Hab ein bisschen probiert, und Recherchiert und habe festgestellt: das geht gar nicht so einfach. Und mit "das geht gar nicht so einfach" meine ich, das geht gar nicht. Es gibt einen Hack, der hier beschrieben ist: http://permalink.gmane.org/gmane.comp.p ... user/15952
Allerdings ist er erstens sehr unschön, andererseits funktioniert er nicht immer.
Ich bitte also darum, dass diejenigen die wirklich vorhaben mit Debugsymbolen zu arbeiten CMake wie folgt aufzurufen:

Code: Alles auswählen

cmake -DCMAKE_BUILD_TYPE=Debug /pfad/zum/source

Zu den anderen Änderungen:
Ich habe das Verzeichnis "test" (mit zugehörigen CMakeLists.txt) erstellt, es soll alle Testexecutables beherbergen. Das habe ich auch in den Haupt-Build eingeklinkt,
ALLERDINGS: als EXCLUDE_FROM_ALL, das bedeutet dass die Tests nicht gebaut werden, wenn man nur "make" oder "make all" eingibt. Das betrifft gerade "scanner", filesearch/main.cpp habe ich nach test/testfilesearch.cpp verschoben, diese wird auch standardmäßig nicht gebaut. Will jemand das ding bauen, bitte
"make scanner" benutzen.

Over and out.

[fat-lobyte]

Hallo an die lieben Mitentwickler,

wer sich schon mal gefragt hat was dieses komische "CMake" dingsda ist, ich habe eine nette Präsentation gefunden, die einen kleinen Überblick über CMake/CTest/CPack gibt:

http://www.kde.org/kdeslides/CampKDE201 ... anwell.pdf

Bei Gelegenheit mal durchblättern!

mfg, fat-lobyte

[Bebu]

Ich möchte unseren Bild-Experten daran erinnern, das uns noch ein find_package für Sqlite fehlt. Ich habe heute vergeblich versucht, so etwas einzubauen und hoffe jetzt, dass du mehr Erfolg hast, als ich.

[fat-lobyte]

Ich möchte unseren Bild-Experten daran erinnern, das uns noch ein find_package für Sqlite fehlt. Ich habe heute vergeblich versucht, so etwas einzubauen und hoffe jetzt, dass du mehr Erfolg hast, als ich.

Wird erledigt, richtzeit Wochenende. Ich bitte dann um ganz viel Testen auf ganz vielen Systemen mit ganz vielen Versionen.