Da Ubuntu die Bibliothek gnet nicht mehr enthält, läßt sich FreeDoko in der aktuellen Version 16.04 nicht mehr bauen. Da gnet seit 2008 (!) kein Update mehr erfahren hat, scheint es mir tot zu sein. Auch die Abhängigkeiten zu gtkmm-2 etc. sollten vielleicht durch gtkmm-3 ersetzt werden.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
gnet wird nicht mehr weitergepflegt und hat schon seit längerem einen Nachfolger. Wir verwenden es noch, weil es funktioniert und wir daher keine Notwendigkeit sahen, umzustellen. Nun haben wir einen Anreiz, ich nehme das auf meine Merkliste mit auf. FreeDoko lässt sich einfach ohne gnet (und damit ohne Netzwerkunterstützung) bauen, dazu in der Makefile.lokal die Zeile
#USE_NETWORK = true
durch
USE_NETWORK = false
ersetzen.
An der Umstellung von gtkmm-2.4 auf gtkmm-3 arbeite ich gerade. Ich habe allerdings dabei noch das Problem, dass ich unter Microsoft Windows noch kein gtkmm-3-Programm zum Laufen bekommen habe, die stürzen immer beim Start ab.
Gruß
Diether
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich würde dieses Thema gerne noch einmal aufgreifen. Da es seit Ihrer Antwort keine neue Version gab, vermute ich, daß gnet immer noch verwendet wird? Leider ist das abschalten der Netzwerkfunktion keine Lösung, da meine Frau und ich gerne gegeneinander über das Netz spielen. ;-)
Grüße
- Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Beim Bauen (mit g++ 6.2) sind ein paar Warnings aufgetreten (-Wmisleading-indentation und -Waddress, letzterer ist möglicherweise ernstzunehmen), die wg. -Werror zum Abbruch des Compilierens führen.
Und daß "make install" nicht einfach von compile abhängig ist, sondern das Programm (mit explizit und ggf. anders gesetzten Variablen) neu baut, ist eigentlich auch ein Fehler.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Eine neue Version wird es spätestens Anfang 2017 geben. Ich habe bei InnoCard angefrag, ob wir die Lizenz für die Verwendung des Kartensatzes verlängern können und warte auf eine Antwort.
Die Umstellung auf gtkmm3 ist fast vollständig abgeschlossen, nur Oberfläche für die Netzwerkeinstellungen fehlt noch, das gehe ich als nächstes an. Mit Windows kommen wir auch mitlerweile klar.
gnet verwenden wir noch weiterhin, das plane ich 2017 durch das Netzwerkmodul von glibmm zu ersetzen.
Mir ist es wichtig, FreeDoko direkt aus dem Verzeichnis starten zu können, ohne es erst installieren zu müssen. Beim normalen make werden daher relative Pfade verwendet (../data für das Datenverzeichnis). Das ist bei make install nicht sinnvoll, daher wird FreeDoko mit absoluten Pfaden zu den Daten neu kompiliert.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
g++ -c ./game/game.announcement.cpp
game.announcement.cpp: In member function ‘Game::AnnouncementWithTrickno Game::announcement_of_team(const TEAM::Team&) const’:
game.announcement.cpp:79:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
if ( this->rule()(Rule::KNOCKING)
^~
game.announcement.cpp:83:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
if ((*p)->team() == team)
^~
g++ -c ./player/ai/ai.cpp
In file included from ../../constants.h:221:0,
from ../constants.h:32,
from constants.h:32,
from ai.cpp:29:
ai.cpp: In member function ‘virtual HandCards Ai::poverty_shift()’:
../../debug.h:259:5: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
} else
^
../../debug.h:262:37: note: in expansion of macro ‘DEBUG_ASSERTION’
#define DEBUG_ASSERT( predicate ) DEBUG_ASSERTION(predicate, "failed")
^~~~~~~~~~~~~~~
ai.cpp:3608:3: note: in expansion of macro ‘DEBUG_ASSERT’
DEBUG_ASSERT(this->hand().numberoftrumps() <= 5 );
^~~~~~~~~~~~
ai.cpp:3610:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
{ // bug report replay
^
g++ -c ./card/trick.cpp
trick.cpp: In member function ‘Trick Trick::till_card(unsigned int) const’:
trick.cpp:438:3: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (unsigned i = 0; i <= c; ++i)
^~~
trick.cpp:441:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
return t;
^~~~~~
g++ -c ./ui/gtkmm/game_summary.cpp
game_summary.cpp: In member function ‘void UI_GTKMM_NS::GameSummary::update()’:
game_summary.cpp:364:18: warning: the compiler can assume that the address of ‘party’ will never be NULL [-Waddress]
if (&party == NULL)
^
g++ -c ./ui/gtkmm/preferences.cpp
preferences.cpp: In member function ‘void UI_GTKMM_NS::Preferences::save()’:
preferences.cpp:986:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
if (::setting(Setting::AUTOMATIC_SAVINGS))
^~
preferences.cpp:989:7: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
return ;
^~~~~~
g++ -c ./os/os.cpp
In file included from ../constants.h:221:0,
from constants.h:32,
from os.cpp:29:
os.cpp: In function ‘OS* new_OS(OS_TYPE::OSType)’:
../debug.h:259:5: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
} else
^
os.cpp:167:5: note: in expansion of macro ‘DEBUG_ASSERTION’
DEBUG_ASSERTION(false,
^~~~~~~~~~~~~~~
os.cpp:171:7: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
return NULL;
^~~~~~
Last edit: knob-creek 2016-12-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bzgl. make targets: bei Open-Source-Projekten ist es üblich, die Quellen mit make zu bauen und mit sudo make install anschließend zu installieren. Von daher ist die komplett unterschiedliche Bedeutung von make compile und make install etwas verwirrend, zumal Ihr Hinweis von April (Änderung in Makefile.local) damit ausgehebelt wird.
Da der Anwender / Integrator einer Distibution an einer Ausführung im build-Verzeichnis eher nicht interessiert ist, würde ich das compile Target aus der Dokumentation herausnehmen.
(Haben Sie schon einmal über autoconf nachgedacht?)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Die Fehler/Warnungen habe ich (vermutlich) im svn-Repository korrigiert.
Das make install werde ich überarbeiten, bisher gab es noch keinen entsprechenden Wunsch. Das wird aber auch erst 2017 etwas.
Der Hauptgrund, dass wir autoconf nicht verwenden ist, dass wir das Kompilieren auch unter Windows in gleicher Form unterstützen. Dazu haben wir unser Makefile-System aufgebaut. Damit können wir unter Linux und Windows einfach mit make (aus einer Shell / DOS-Shell) kompilieren. Autoconf benötigt unter Windows gleich eine unix-artige Umgebung, das brauchen wir nicht. Ich habe mir mal mehrere configure-Skripte angeschaut. Die fand ich ziemlich überladen und allgemein auch nervig in der Anwendung. Ich habe auch keinen wirklichen Mehrwert vom configure-Skript gesehen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Der Sinn von autoconf ist, auf verschiedenen (Unix-)Plattformen automatisch zu erkennen, welche Bibliotheken in welcher Version verfügbar sind. Im Falle fehlender Verfügbarkeit können Features abgeschaltet werden oder eine Fehlermeldung erzeugt werden. Für die Integration in unterschiedliche Linux-Distributionen ist das ein erheblicher Vorteil.
Die Entwicklung unter Windows ist mir völlig fremd, daher kann ich dazu nichts sagen. Alles, was ich dort je gemacht habe (außer JAVA-Entwicklung, aber das ist ein anderes Universum), begann mit der Installation der cygwin-Tools.
Da Sie vollständig auf Linux-basierte OSS-Bibliotheken setzen, hätte ich gedacht, daß eine Linux-ähnliche Umgebung unter Windows Ihnen das Leben leichter macht (und cygwin wird von autoconf unterstützt).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Da Ubuntu die Bibliothek gnet nicht mehr enthält, läßt sich FreeDoko in der aktuellen Version 16.04 nicht mehr bauen. Da gnet seit 2008 (!) kein Update mehr erfahren hat, scheint es mir tot zu sein. Auch die Abhängigkeiten zu gtkmm-2 etc. sollten vielleicht durch gtkmm-3 ersetzt werden.
Hallo,
gnet wird nicht mehr weitergepflegt und hat schon seit längerem einen Nachfolger. Wir verwenden es noch, weil es funktioniert und wir daher keine Notwendigkeit sahen, umzustellen. Nun haben wir einen Anreiz, ich nehme das auf meine Merkliste mit auf. FreeDoko lässt sich einfach ohne gnet (und damit ohne Netzwerkunterstützung) bauen, dazu in der Makefile.lokal die Zeile
durch
ersetzen.
An der Umstellung von gtkmm-2.4 auf gtkmm-3 arbeite ich gerade. Ich habe allerdings dabei noch das Problem, dass ich unter Microsoft Windows noch kein gtkmm-3-Programm zum Laufen bekommen habe, die stürzen immer beim Start ab.
Gruß
Diether
Ich würde dieses Thema gerne noch einmal aufgreifen. Da es seit Ihrer Antwort keine neue Version gab, vermute ich, daß gnet immer noch verwendet wird? Leider ist das abschalten der Netzwerkfunktion keine Lösung, da meine Frau und ich gerne gegeneinander über das Netz spielen. ;-)
Grüße
- Thomas
Beim Bauen (mit g++ 6.2) sind ein paar Warnings aufgetreten (-Wmisleading-indentation und -Waddress, letzterer ist möglicherweise ernstzunehmen), die wg. -Werror zum Abbruch des Compilierens führen.
Und daß "make install" nicht einfach von compile abhängig ist, sondern das Programm (mit explizit und ggf. anders gesetzten Variablen) neu baut, ist eigentlich auch ein Fehler.
Eine neue Version wird es spätestens Anfang 2017 geben. Ich habe bei InnoCard angefrag, ob wir die Lizenz für die Verwendung des Kartensatzes verlängern können und warte auf eine Antwort.
Die Umstellung auf gtkmm3 ist fast vollständig abgeschlossen, nur Oberfläche für die Netzwerkeinstellungen fehlt noch, das gehe ich als nächstes an. Mit Windows kommen wir auch mitlerweile klar.
gnet verwenden wir noch weiterhin, das plane ich 2017 durch das Netzwerkmodul von glibmm zu ersetzen.
Mir ist es wichtig, FreeDoko direkt aus dem Verzeichnis starten zu können, ohne es erst installieren zu müssen. Beim normalen make werden daher relative Pfade verwendet (../data für das Datenverzeichnis). Das ist bei make install nicht sinnvoll, daher wird FreeDoko mit absoluten Pfaden zu den Daten neu kompiliert.
Was für Fehler/Warnungen werden denn ausgegeben?
g++ -c ./game/game.announcement.cpp game.announcement.cpp: In member function ‘Game::AnnouncementWithTrickno Game::announcement_of_team(const TEAM::Team&) const’: game.announcement.cpp:79:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if ( this->rule()(Rule::KNOCKING) ^~ game.announcement.cpp:83:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’ if ((*p)->team() == team) ^~g++ -c ./player/ai/ai.cpp In file included from ../../constants.h:221:0, from ../constants.h:32, from constants.h:32, from ai.cpp:29: ai.cpp: In member function ‘virtual HandCards Ai::poverty_shift()’: ../../debug.h:259:5: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation] } else ^ ../../debug.h:262:37: note: in expansion of macro ‘DEBUG_ASSERTION’ #define DEBUG_ASSERT( predicate ) DEBUG_ASSERTION(predicate, "failed") ^~~~~~~~~~~~~~~ ai.cpp:3608:3: note: in expansion of macro ‘DEBUG_ASSERT’ DEBUG_ASSERT(this->hand().numberoftrumps() <= 5 ); ^~~~~~~~~~~~ ai.cpp:3610:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’ { // bug report replay ^g++ -c ./card/trick.cpp trick.cpp: In member function ‘Trick Trick::till_card(unsigned int) const’: trick.cpp:438:3: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation] for (unsigned i = 0; i <= c; ++i) ^~~ trick.cpp:441:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’ return t; ^~~~~~g++ -c ./ui/gtkmm/game_summary.cpp game_summary.cpp: In member function ‘void UI_GTKMM_NS::GameSummary::update()’: game_summary.cpp:364:18: warning: the compiler can assume that the address of ‘party’ will never be NULL [-Waddress] if (&party == NULL) ^g++ -c ./ui/gtkmm/preferences.cpp preferences.cpp: In member function ‘void UI_GTKMM_NS::Preferences::save()’: preferences.cpp:986:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (::setting(Setting::AUTOMATIC_SAVINGS)) ^~ preferences.cpp:989:7: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’ return ; ^~~~~~g++ -c ./os/os.cpp In file included from ../constants.h:221:0, from constants.h:32, from os.cpp:29: os.cpp: In function ‘OS* new_OS(OS_TYPE::OSType)’: ../debug.h:259:5: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation] } else ^ os.cpp:167:5: note: in expansion of macro ‘DEBUG_ASSERTION’ DEBUG_ASSERTION(false, ^~~~~~~~~~~~~~~ os.cpp:171:7: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’ return NULL; ^~~~~~Last edit: knob-creek 2016-12-03
Bzgl. make targets: bei Open-Source-Projekten ist es üblich, die Quellen mit make zu bauen und mit sudo make install anschließend zu installieren. Von daher ist die komplett unterschiedliche Bedeutung von make compile und make install etwas verwirrend, zumal Ihr Hinweis von April (Änderung in Makefile.local) damit ausgehebelt wird.
Da der Anwender / Integrator einer Distibution an einer Ausführung im build-Verzeichnis eher nicht interessiert ist, würde ich das compile Target aus der Dokumentation herausnehmen.
(Haben Sie schon einmal über autoconf nachgedacht?)
Die Fehler/Warnungen habe ich (vermutlich) im svn-Repository korrigiert.
Das make install werde ich überarbeiten, bisher gab es noch keinen entsprechenden Wunsch. Das wird aber auch erst 2017 etwas.
Der Hauptgrund, dass wir autoconf nicht verwenden ist, dass wir das Kompilieren auch unter Windows in gleicher Form unterstützen. Dazu haben wir unser Makefile-System aufgebaut. Damit können wir unter Linux und Windows einfach mit make (aus einer Shell / DOS-Shell) kompilieren. Autoconf benötigt unter Windows gleich eine unix-artige Umgebung, das brauchen wir nicht. Ich habe mir mal mehrere configure-Skripte angeschaut. Die fand ich ziemlich überladen und allgemein auch nervig in der Anwendung. Ich habe auch keinen wirklichen Mehrwert vom configure-Skript gesehen.
Der Sinn von autoconf ist, auf verschiedenen (Unix-)Plattformen automatisch zu erkennen, welche Bibliotheken in welcher Version verfügbar sind. Im Falle fehlender Verfügbarkeit können Features abgeschaltet werden oder eine Fehlermeldung erzeugt werden. Für die Integration in unterschiedliche Linux-Distributionen ist das ein erheblicher Vorteil.
Die Entwicklung unter Windows ist mir völlig fremd, daher kann ich dazu nichts sagen. Alles, was ich dort je gemacht habe (außer JAVA-Entwicklung, aber das ist ein anderes Universum), begann mit der Installation der cygwin-Tools.
Da Sie vollständig auf Linux-basierte OSS-Bibliotheken setzen, hätte ich gedacht, daß eine Linux-ähnliche Umgebung unter Windows Ihnen das Leben leichter macht (und cygwin wird von autoconf unterstützt).
Anderes Thema -> anderer Thread
Last edit: knob-creek 2016-12-03