Build-System

[fat-lobyte]

Hallo!

Dieses Thema soll das "offizielle" Diskussionsthema zum Buildsystem sein.

Hier sollte das "Build-Team", zurzeit Kerli und ich einerseits Ankündigungen die alle betreffen posten, zum anderen ist es ein Platz für alle anderen Entwickler Dampf abzulassen. Das Betrifft:

• Fragen jeglicher Art zum Bau-System
• Fragen zur Installation und Einrichtung von Bibliotheken und Compilern
• Fehlermeldungen des Bau-Systems(siehe unten für Kriterien)
• Vorschläge zur Verbesserung, z.B. der portabilität, Geschwindigkeit, Redundanz, Flexibilität, ...

Fehler berichten
Dass nicht jeder Compilerfehler ein Fehler des Bau-Systems ist, sollte hoffentlich klar sein. Deswegen hier die Regeln, was denn so als "Fehler des Bau-Systems" gilt:

• Linker-Fehler jeglicher Art
• Compilerfehler die auf fehlende Headerdateien zurückgeführt werden können
• Fehlermeldungen von CMake, obwohl alle benötigten Abhängigkeiten installiert sind
• Warnungen von CMake
• Fehlermeldungen zur Zeit des Ausführens, die mit fehlenden Laufzeitbibliotheken zu tun haben

Trifft einer oder mehrere dieser Punkte auf euer Problem zu, bitte beschreibt den Fehler, und gebt folgende Informationen bekannt:

Verwendetes Betriebssystem:
- Familie (Linux/Windows/MacOS/FreeBSD/Solaris/...)
- Distribution, wenn Unixartig (Debian/Ubuntu/Fedora/ ...)
- Version (Squeeze, Fedora 13, Vista, XP, Tiger, ...)

Verwendete Toolkette (also Compiler)
- CMake Version
- Compilername und Version (GCC, Visual Studio, ...)
- IDE, wenn verwendet (Eclipse, Visual Studio, Codelite...)

Genauer Aufruf des Buildsystems (Kopie der Kommandozeile bei cmake, screenshot bei cmake-gui)

Genaue Ausgabe des Buildsystems (bitte in code Tags!!)
- Bei kompilieren mit make bitte "VERBOSE=1" zum Aufruf von Make hinzufügen
- Ausgabe in der Kommandozeile oder
- Ausgabe im Debugfenster der IDE

Bei happigen fällen:
Verwendeter CMake Generator (-G option, wenn verwendet)
Installierte Bibliotheken
Folgende Umgebungsvariablen:
- PATH
- Bei GCC: CPATH, CPATH, CPLUS_INCLUDE_PATH, LIBRARY_PATH
- Bei MSVC: INCLUDE, LIB, LIBPATH

Dieses Infos helfen der schnellen Fehlerbehebung.

Also dann, fröhliches Bauen!

[fat-lobyte]

Hier gleich mal die erste Ankündigung.
Vor kurzem habe ich ein paar Commits gemacht, die das Bausystem ein bisschen umgemöbelt haben. Dabei ist folgendes passiert:

CMakeHelloworld, also die main.cpp im Projektverzeichnis und die pseudobibliothek "library" ist rausgeflogen.
Stattdessen gibt es eine main.cpp unter /gui/ncurses, die ein ncurses-Hallowelt darstellt.
Diese wird nun Standardmäßig gebaut, dafür ist allerdings die NCurses Bibliothek zu installieren. (Infos dazu bitte selbst einholen, die kommen erst später ins Readme. Stichwort für Windows User: http://gnuwin32.sourceforge.net/packages/ncurses.htm).

Das wars mal fürs erste. Für die Nahe zukunft stehen noch einige Umbauten auf den Plan, aber alles zu seiner Zeit.

In diesem Sinne: Happy hacking,
fat-lobyte

[cloidnerux]

Ähm, ich weiß ja nicht obs hier hin passt, aber ich finde keine Möglichkeit ncurses herunterzuladen. Ich bekomme nur ein 404 und Links zur Dokumentation.
Auf Sourceforge finde ich keine Erwähnung von ncurses. Ist das Projekt gerade nicht erreichbar oder sehe ich den Wald vor lauter Bäumen nicht?

[fat-lobyte]

Ähm, ich weiß ja nicht obs hier hin passt, aber ich finde keine Möglichkeit ncurses herunterzuladen. Ich bekomme nur ein 404 und Links zur Dokumentation.
Auf Sourceforge finde ich keine Erwähnung von ncurses. Ist das Projekt gerade nicht erreichbar oder sehe ich den Wald vor lauter Bäumen nicht?

Tatsächlich. Das Projekt scheint eingeschlafen zu sein... versuchs mal mit diesen Links:
http://pdcurses.sourceforge.net/
http://sourceforge.net/projects/pdcurses/files/

Ich werd mir später mal was Runterladen und kompilieren Versuchen, dann schreib ichs ins README (oder hier hinein).

Die nächsten Änderungen:

Standardmäßig werden jetzt dynamische statt statische Bibliotheken erstellt. Gibt es damit Probleme dann postet sie erstens hierher, zweitens könnt ihr das Abstellen und auf statische Bibliotheken zurückschalten indem ihr CMake die "-DBUILD_SHARED_LIBS=OFF" übergebt.

Des weiteren gibts jetzt ein Install target, ihr könnt das Programm nach dem Bauen mit

Code: Alles auswählen

make install

installieren.

Auf Linux tut das folgendes:
Installiert standardmäßig nach /usr/local/bin und /usr/local/lib. Ändern des Installationsverzeichnisses durch übergeben der Option "-DCMAKE_INSTALL_PREFIX=/pfad/zum/verzeichnis".
Je nach Verzeichnis benötigt man Root-Rechte für diese Operation

Auf Windows:
Installiert nach "C:\Program Files", bzw. "C:\Programme". Ändern des Installationsverzeichnisses durch übergeben der Option "-DCMAKE_INSTALL_PREFIX=/pfad/zum/verzeichnis". Je nach Verzeichnis muss man die Console, aus der das Target aufgerufen wird als Administrator starten.

[fat-lobyte]

Tatsächlich. Das Projekt scheint eingeschlafen zu sein... versuchs mal mit diesen Links:
http://pdcurses.sourceforge.net/
http://sourceforge.net/projects/pdcurses/files/

Ähm, ja ^^
Es baut schon mal. Wie ist eine andere Frage, ich würde sagen mehr schlecht als recht. Als Beweis versuch ich mal die Executables anzuhängen.Ah, tatsächlich, es ging:

dedupe-r59.zip

Hier meine magische cmd session, als anhaltspunkt:

Code: Alles auswählen

c:\Users\alexander\Documents\dedupe\build>cmake -G "NMake Makefiles" "-DCURSES_INCLUDE_PATH=..\contrib\pdcurses-win32" -DCURSES_LIBRARY=..\contrib\pdcurses-win32\pdcurses.lib" -DBUILD_SHARED_LIBS=OFF  ..
-- The CXX compiler identification is MSVC
-- Check for CL compiler version
-- Check for CL compiler version - 1600
-- Check if this is a free VC compiler
-- Check if this is a free VC compiler - no
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio 10.0
/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio 10.0
/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Curses: C:/Users/alexander/Documents/dedupe/contrib/pdcurses-win32/pdcu
rses.lib
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/alexander/Documents/dedupe/build
c:\Users\alexander\Documents\dedupe\build>nmake

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target dedupe-hash
[ 33%] Building CXX object hash/CMakeFiles/dedupe-hash.dir/hash32.cpp.obj
hash32.cpp
[ 66%] Building CXX object hash/CMakeFiles/dedupe-hash.dir/hash64.cpp.obj
hash64.cpp
Linking CXX static library dedupe-hash.lib
[ 66%] Built target dedupe-hash
Scanning dependencies of target dedupe-ncurses
[100%] Building CXX object gui/ncurses/CMakeFiles/dedupe-ncurses.dir/main.cpp.ob
j
main.cpp
Linking CXX executable ..\..\dedupe-ncurses.exe
[100%] Built target dedupe-ncurses
c:\Users\alexander\Documents\dedupe\build>copy ..\contrib\pdcurses-win32\pdcurse
s.dll .
        1 Datei(en) kopiert.

Keine sorge, ordentliche Doku kommt noch (irgendwann ^^)

[cloidnerux]

Tatsächlich. Das Projekt scheint eingeschlafen zu sein... versuchs mal mit diesen Links:
http://pdcurses.sourceforge.net/
http://sourceforge.net/projects/pdcurses/files/

Funktioniert unter Win7 + VC2008.
Statt #include <ncurses.h> einfach nur #include <curses.h> schreiben.

Edit: @fat-lobyte: Programm getestet, funzt bei mir, musste nur die "MSVCR100D.dll" nachinstallieren.

[Xin]

Auf Sourceforge finde ich keine Erwähnung von ncurses. Ist das Projekt gerade nicht erreichbar oder sehe ich den Wald vor lauter Bäumen nicht?

Tatsächlich. Das Projekt scheint eingeschlafen zu sein... versuchs mal mit diesen Links:
http://pdcurses.sourceforge.net/
http://sourceforge.net/projects/pdcurses/files/

Solche Links machen sich gut auf der Dedupe-Seite, damit man sie schnell wiederfindet.
Ich habe mal eine Links-Seite dafür eingerichtet.

[fat-lobyte]

Hallo. Ich habe gerade das Build-System etwas upgedatet,
es beinhaltet nun die "dedupe-filesearch" Bibliothek.
Außerdem gibt es nun eine globale CMake Variable Namens SYSTEM_LIBS, die auf die benötigten Systembibliotheken gesetzt wird, die dann zur Ausführbaren Datei gelinkt werden.

Eine Frage habe ich noch:
Zurzeit landen die ausführbaren Dateien im Ordner wo sie gebaut werden, und die Bibliotheken bleiben irgendwo in ihren Unterordnern versteckt. Gibt es präferenzen wo diese Executables landen sollen? Sollen sie ins bin/ verzeichnis relativ zum bauverzeichnis? Oder sollen sie einfach im Bauverzeichnis bleiben? Oder wollt ihr die Executables selbst in ihren Unterverzeichnissen liegen lassen und sie stattdessen mit "make install" installieren?
Was ist euch lieber?

[Bebu]

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

[Xin]

Zurzeit landen die ausführbaren Dateien im Ordner wo sie gebaut werden, und die Bibliotheken bleiben irgendwo in ihren Unterordnern versteckt. Gibt es präferenzen wo diese Executables landen sollen? Sollen sie ins bin/ verzeichnis relativ zum bauverzeichnis? Oder sollen sie einfach im Bauverzeichnis bleiben? Oder wollt ihr die Executables selbst in ihren Unterverzeichnissen liegen lassen und sie stattdessen mit "make install" installieren?
Was ist euch lieber?

Bei meinem Projekten gibt es neben den Quellcodeverzeichnissen (die je nach Projektzugehörigkeit sortiert sind de/xsd/*/*.h|cpp und gr/forth/*/*.h|cpp) sortiert sind zwei weitere Ordner. bin enthält die ausführbaren Programme, obj hat die gleiche Struktur wie die Quellen: z.B. obj/de/xsd/gsys/operator/add.o.

Mein Vorschlag wäre dem zu entsprechen: src, obj, bin.
Theoretisch kann man noch Header und Src trennen, dafür konnte ich mich bisher allerdings nicht begeistern.