Ubuntu-fr

tshirtman

Re : /* Topic des codeurs [6] */

Bah, passer de php à n'importe quoi, en général…

---

Le blog de tshirtman, du python, du shell, du libre, et d'autres choses.
Mon petit frère écrit des trucs biens!
Ultimate smash friends, un smash bros like, libre paquet natty!

HP

Re : /* Topic des codeurs [6] */

C'est pas faux …

---

cat /dev/urandom >/dev/null 2>&1 #github

Rolinh

Re : /* Topic des codeurs [6] */

Plop,

bon, pour me détendre un peu en cette période d'examens, je me suis remis un petit peu sur LinCopier. J'ai repris la CLI de 0 (elle n'avait pas bougé depuis les premiers test je pense étant donné qu'on ne s'était concentré que sur la GUI). Enfin bref, là n'est pas la question.

Le Makefile a été écrit à l'ancienne (comprenez à la main) mais... je n'ai jamais fait de "install" et j'avoue ne pas savoir comment gérer ça du fait que l'on doit pouvoir préciser dans quelles répertoires on désire placer les binaires. Quelqu'un pour me donner une piste? grim?

grim7reaper

Re : /* Topic des codeurs [6] */

Quelqu'un pour me donner une piste? grim?

Je t’avouerais que j’ai plus ou moins laisser tomber les Makefile à la main depuis que je me suis mis à CMake (il est simple à utiliser, possède une syntaxe plus claire que les Makefile, a une bonne doc et est « propre » (il met tout ses fichiers dans un répertoire dédiés et ne te pourri pas ton répertoire de dev’ comme les autohell…)).
Les Makefile ça devient vite chiant, abscons et inmaintenable quand tu veux faire des trucs un peu poussé (vérifier l'existence d’une lib, activer des options à la compil’, être portable, etc).
Les autohell ont été créés pour remédier à cela, mais bon depuis on a fait mieux.

En plus, CMake peut générer autre chose que des Makefile. Par exemple, des fichiers de projet VS, Eclipse, KDevelop, etc. ce qui peut être utile si un gus veut contribuer mais utilise un IDE.

Il existe aussi un autre systèmes de production, codé en Python (CMake c’est du C++ il me semble), appelé Scons. Je ne sais pas grand chose à son sujet (si ce n’est que le Farfadet le mentionne parfois, mais il utilise CMake lui aussi)

Je connais un peu CMake, et xapantu en connait sûrement plus que moi (et il passe ici de temps en temps) donc si tu veux

Dernière modification par grim7reaper (Le 26/01/2012, à 21:34)

---

Blog

Rolinh

Re : /* Topic des codeurs [6] */

Bon, je crois que c'est le moment de regarder du côté de cmake alors. D'autant que je commence à vouloir de plus en plus de choses (2 binaires, une compil "dev" et une compile "perf", préconf, etc.).
Merci.

grim7reaper

Re : /* Topic des codeurs [6] */

Ha bah justement, je pense que tu devrais trouver ton bonheur avec CMake :-)

Il n’y a pas longtemps, j’ai repris un de mes vieux projet et j‘ai remplacé mon Makefile de 242 lignes par un CMakeLists.txt de 83 lignes (et j’ai ajouté des fonctionnalités au passage). La migration ne m’a pas pris longtemps en plus.

Dernière modification par grim7reaper (Le 26/01/2012, à 21:41)

---

Blog

Rolinh

Re : /* Topic des codeurs [6] */

Bon, c'est dans le cas où tu connais déjà cmake. Moi, je ne le connais pas donc ça risque de me prendre un peu de temps. Est-ce le bon endroit pour commencer? => ici

grim7reaper

Re : /* Topic des codeurs [6] */

Oui. Ici aussi c’est pas mal pour s’initier.

Ton Makefile me semble relativement simple, si tu veux je peux te le réécrire vite fait et ensuite tu peaufines.

Dernière modification par grim7reaper (Le 26/01/2012, à 21:49)

---

Blog

Rolinh

Re : /* Topic des codeurs [6] */

Ok, ça va me faire un peu de lecture. Merci. Je risque de venir poser quelques questions un de ces 4 ^^.

The Uploader

Re : /* Topic des codeurs [6] */

Projet IA rendu (\o/), je ne toucherai plus jamais à de l'ActionScript, JAMAIS ! è_é

commit 385d8530f68b6826ec2632938eedabd1c7216267
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Fri Jan 27 00:11:06 2012 +0100

    removed repetition and BIGGER_RESOURCE not true bug

diff --git a/src/com/Antubis/AntubisBot.as b/src/com/Antubis/AntubisBot.as
index 0fa9ea7..f4d79af 100644
--- a/src/com/Antubis/AntubisBot.as
+++ b/src/com/Antubis/AntubisBot.as
@@ -144,7 +144,7 @@
                 if (IsCloser(seenResource)) {
                     expertSystem.SetFactValue(CustomBotFacts.CLOSER_RESOURCE, true);
                 } 
-                if (takenResource && seenResource.GetLife() > takenResourceLife) {
+                if (takenResourceLife && seenResource.GetLife() > takenResourceLife) {
                     expertSystem.SetFactValue(AgentFacts.BIGGER_RESOURCE, true);
                 }
             } else {
@@ -162,10 +162,6 @@
             if (IsAtHome()) {
                 expertSystem.SetFactValue(AgentFacts.AT_HOME, true);
             }
-            
-            if (hasResource) {
-                expertSystem.SetFactValue(AgentFacts.GOT_RESOURCE, true);
-            }
         }
         
         public override function onAgentCollide(_event:AgentCollideEvent) : void  {

commit 9241c5bc6212dbbdc89b8ab0264c93f2934d2e03
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Jan 26 14:52:54 2012 +0100

    chat about seenEnemyBot too. Made seenPhero public too.

diff --git a/src/com/Antubis/AntubisBot.as b/src/com/Antubis/AntubisBot.as
index f5fa8c2..0fa9ea7 100644
--- a/src/com/Antubis/AntubisBot.as
+++ b/src/com/Antubis/AntubisBot.as
@@ -23,8 +23,8 @@
         
         protected static const EDGE_LIMIT:Number= 6;
         protected var stolen:Boolean             = false;
-        protected var seenPhero:Phero;
-        protected var seenEnemyBot:Point;
+        public var seenPhero:Phero;
+        public var seenEnemyBot:Point;
         protected var seenTeamBot:AntubisBot;
         protected var lastSeenResource:Point;
         protected var takenResourceLife:Number;
@@ -210,6 +210,9 @@
             if (!seenPhero) {
                 seenPhero = chatBot.seenPhero;
             }
+            if (!seenEnemyBot) {
+                seenEnemyBot = chatBot.seenEnemyBot;
+            }
         }
         
         protected override function Act() : void {

commit aef8df4a09fb2b40abd1c798943881eff59321f8
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Jan 26 11:41:05 2012 +0100

    chat also about seenPhero

diff --git a/src/com/Antubis/AntubisBot.as b/src/com/Antubis/AntubisBot.as
index d660b10..f5fa8c2 100644
--- a/src/com/Antubis/AntubisBot.as
+++ b/src/com/Antubis/AntubisBot.as
@@ -199,13 +199,16 @@
             }
         }
         
-        protected function Chat(_seenBot:AntubisBot) : void {
+        protected function Chat(chatBot:AntubisBot) : void {
             CorrectLastSeenResource();
             if (!lastSeenResource) {
-                lastSeenResource = _seenBot.GetLastSeenResource();
+                lastSeenResource = chatBot.GetLastSeenResource();
             }
-            if (_seenBot.GetHomePosition()) {
-                homePosition = _seenBot.GetHomePosition();
+            if (chatBot.GetHomePosition()) {
+                homePosition = chatBot.GetHomePosition();
+            }
+            if (!seenPhero) {
+                seenPhero = chatBot.seenPhero;
             }
         }
         

commit c7cc4f270d7cf64fcb1f7188d84383a8be3ab1bf
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Jan 26 11:36:19 2012 +0100

    longer resetTimer so AntubisBot doesn't stay on a Phero

diff --git a/src/com/Antubis/AntubisBot.as b/src/com/Antubis/AntubisBot.as
index 452dd05..d660b10 100644
--- a/src/com/Antubis/AntubisBot.as
+++ b/src/com/Antubis/AntubisBot.as
@@ -46,7 +46,7 @@
             seenEnemyBot = null;
             seenTeamBot = null;
             stolen = false;
-            if (resetTimer >= Phero.BASE_LIFETIME*World.RESOURCE_START_LIFE) {
+            if (resetTimer >= Phero.BASE_LIFETIME*World.RESOURCE_START_LIFE*2) {
                 passedPheros = new Array();
                 resetTimer = 0;
             }

commit a5a1d42ae18b490f95c71e35ac96cbd9713a2b78
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Jan 26 11:30:17 2012 +0100

    Faster change of mode for PheroBot

diff --git a/src/com/Antubis/PheroBot.as b/src/com/Antubis/PheroBot.as
index 1d3be2a..9c1f5e9 100644
--- a/src/com/Antubis/PheroBot.as
+++ b/src/com/Antubis/PheroBot.as
@@ -20,17 +20,7 @@ package com.Antubis
         }
         
         public override function Update() : void {
-            if (reachedResource && !antubisMode) {
-                antubisMode = true;
-                pheroMode = false;
-                super.InitExpertSystem();
-            }
-            if (!seenResource && !lastSeenResource && !hasResource && !pheroMode) {
-                antubisMode = false;
-                pheroMode = true;
-                InitExpertSystem();
-            }
-            
+            CheckMode();
             super.Update();
         }
         
@@ -56,6 +46,11 @@ package com.Antubis
                                                                                     CustomBotFacts.NOT_GOING_TO_RESOURCE)));
         }
         
+        public override function onAgentCollide(_event:AgentCollideEvent) : void  {
+            super.onAgentCollide(_event);
+            CheckMode();
+        }
+        
         protected override function UpdateFacts() : void {
             var lastSeenPhero:Phero = lastDropedPhero != null ? lastDropedPhero : seenPhero;
             if (lastSeenPhero) {
@@ -84,5 +79,18 @@ package com.Antubis
         protected function DropPhero() : void {
             Drop(lastDropedPhero = new Phero(AntubisAgentType.PHERO, Phero.BASE_LIFETIME*seenResource.GetLife()));
         }
+        
+        protected function CheckMode() : void {
+            if (reachedResource && !antubisMode) {
+                antubisMode = true;
+                pheroMode = false;
+                super.InitExpertSystem();
+            }
+            if (!seenResource && !lastSeenResource && !hasResource && !pheroMode) {
+                antubisMode = false;
+                pheroMode = true;
+                InitExpertSystem();
+            }
+        }
     }
 }

Avec un document en PDF décrivant la stratégie des bots, les bases de faits et de règles, les actions sur le monde, et l'effet de masse.

Dernière modification par The Uploader (Le 27/01/2012, à 00:20)

---

- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

grim7reaper

Re : /* Topic des codeurs [6] */

Tu pourrais m’envoyer ton projet (PDF + code) si tu as le droit.
Ça m’intéresse d’y jeter un œil (comme tu t’en doutes c’est pour le côté IA, pas ActionScript ).

Dernière modification par grim7reaper (Le 27/01/2012, à 08:18)

---

Blog

The Uploader

Re : /* Topic des codeurs [6] */

Fait.

(je rendrai à nouveau le tout publique sur github dans quelques temps)

---

- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Rolinh

Re : /* Topic des codeurs [6] */

@grim: tu pourrais me passer un de tes CMakeLists.txt ?

grim7reaper

Re : /* Topic des codeurs [6] */

@The Uploader : Reçu.
Merci

@Rolinh : bah en fait j’en ai pas mal de différent selon ce que je voulais faire. Le mieux ça serait que tu me dises ce que tu veux faire (compilation optionnelle de la GUI, création de bibliothèque, génération d’un config.h, etc.) et je te poste un exemple de mise en œuvre si j’en ai un sous la main.
En attendant, voilà ce que j’ai fait pour lincopier (ça reste grandement améliorable je pense, pour le moment j’ai retranscrit rapidement et grossièrement ton Makefile original).

cmake_minimum_required(VERSION 2.8)
project(Lincopier)

set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/CMakeModules)

include(FindGTK3)
include(FindGObject)
include(FindThreads)

find_package(GTK3 REQUIRED)
find_package(GObject REQUIRED)
find_package(Threads REQUIRED)

include_directories(${GTK3_INCLUDE_DIRS})

add_executable(lincopier
"main.c"
"utils.c"
"copy.c"
"queue.c"
"gui.c"
"log.c"
)
target_link_libraries(lincopier
${GTK3_LIBRARY_DIRS}
${GOBJECT_LIBRARIES}
${CMAKE_THREAD_LIBS_INIT}
)

add_executable(lincopier-cli
"main-cli.c"
"utils.c"
"copy.c"
"queue.c"
"gui.c"
"log.c"
)
target_link_libraries(lincopier-cli
${GTK3_LIBRARY_DIRS}
${GOBJECT_LIBRARIES}
${CMAKE_THREAD_LIBS_INIT}
)

À noter que tu dois créer un répertoire CMakeModules dans ton répertoire src (le nom et la localisation de ce répertoire peuvent changer, faut juste modifier la variable CMAKE_MODULE_PATH en conséquence).
Ce répertoire devra contenir les deux fichiers suivants (que j’ai récupérer après quelques recherche, ne te fatigues pas à comprendre car c’est très rare que tu doives écrire ce genre de fichier toi-même, seul le CMakeLists.txt est important), car ils ne sont pas inclus dans les modules par défaut de CMake, ça viendra peut-être (pour le moment CMake offre des modules de recherches pour GTK 1 et GTK 2, mais pas encore GTK 3).

FindGTK3.cmake

# - Find gtk3, glib
# Defines:
# GTK3_FOUND
# GTK3_INCLUDE_DIRS
# GTK3_LIBRARY_DIRS
# GTK3_DEFINITIONS
# GTK3_DEFINITIONS

FIND_PACKAGE(PkgConfig)

#
# gtk
#
PKG_CHECK_MODULES(PC_GTK3 REQUIRED gtk+-3.0)

SET(GTK3_DEFINITIONS ${PC_GTK3_CXXFLAGS_OTHER})

FIND_PATH(
  GTK3_INCLUDE_DIR gtk/gtk.h
  HINTS ${PC_GTK3_INCLUDEDIR} ${PC_GTK3_INCLUDE_DIRS}
  PATH_SUFFIXES gtk-3.0)

FIND_LIBRARY(
  GTK3_LIBRARY NAMES gtk-3
  HINTS ${PC_GTK3_LIBDIR} ${PC_GTK3_LIBRARY_DIRS})

#
# glib
#
PKG_CHECK_MODULES(PC_GLIB2 REQUIRED glib-2.0)

SET(GLIB2_DEFINITIONS ${PC_GLIB2_CXXFLAGS_OTHER})

FIND_PATH(
  GLIB2_INCLUDE_DIR_PART1 glib.h
  HINTS ${PC_GLIB2_INCLUDEDIR} ${PC_GLIB2_INCLUDE_DIRS}
  PATH_SUFFIXES glib-2.0)

FIND_PATH(
  GLIB2_INCLUDE_DIR_PART2 glibconfig.h
  HINTS ${PC_GLIB2_INCLUDEDIR} ${PC_GLIB2_INCLUDE_DIRS}
  PATH_SUFFIXES glib-2.0/include)

SET(GLIB2_INCLUDE_DIR ${GLIB2_INCLUDE_DIR_PART1} ${GLIB2_INCLUDE_DIR_PART2})

FIND_LIBRARY(
  GLIB2_LIBRARY NAMES glib-2.0
  HINTS ${PC_GLIB2_LIBDIR} ${PC_GLIB2_LIBRARY_DIRS})

#
# pango
#
PKG_CHECK_MODULES(PC_PANGO REQUIRED pango)

SET(PANGO_DEFINITIONS ${PC_PANGO_CXXFLAGS_OTHER})

FIND_PATH(
  PANGO_INCLUDE_DIR pango/pango.h
  HINTS ${PC_PANGO_INCLUDEDIR} ${PC_PANGO_INCLUDE_DIRS}
  PATH_SUFFIXES pango-1.0)

FIND_LIBRARY(
  PANGO_LIBRARY NAMES pango-1.0
  HINTS ${PC_PANGO_LIBDIR} ${PC_PANGO_LIBRARY_DIRS})

#
# cairo
#
PKG_CHECK_MODULES(PC_CAIRO REQUIRED cairo)

SET(CAIRO_DEFINITIONS ${PC_CAIRO_CXXFLAGS_OTHER})

FIND_PATH(
  CAIRO_INCLUDE_DIR cairo.h
  HINTS ${PC_CAIRO_INCLUDEDIR} ${PC_CAIRO_INCLUDE_DIRS}
  PATH_SUFFIXES cairo)

FIND_LIBRARY(
  CAIRO_LIBRARY NAMES cairo
  HINTS ${PC_CAIRO_LIBDIR} ${PC_CAIRO_LIBRARY_DIRS})

#
# gdk-pixbuf
#
PKG_CHECK_MODULES(PC_GDKPIXBUF REQUIRED gdk-pixbuf-2.0)

SET(GDKPIXBUF_DEFINITIONS ${PC_GDKPIXBUF_CXXFLAGS_OTHER})

FIND_PATH(
  GDKPIXBUF_INCLUDE_DIR gdk-pixbuf/gdk-pixbuf.h
  HINTS ${PC_GDKPIXBUF_INCLUDEDIR} ${PC_GDKPIXBUF_INCLUDE_DIRS}
  PATH_SUFFIXES gdk-pixbuf-2.0)

FIND_LIBRARY(
  GDKPIXBUF_LIBRARY NAMES gdk_pixbuf-2.0
  HINTS ${PC_GDKPIXBUF_LIBDIR} ${PC_GDKPIXBUF_LIBRARY_DIRS})

#
# atk
#
PKG_CHECK_MODULES(PC_ATK REQUIRED atk)

SET(ATK_DEFINITIONS ${PC_ATK_CXXFLAGS_OTHER})

FIND_PATH(
  ATK_INCLUDE_DIR atk/atk.h
  HINTS ${PC_ATK_INCLUDEDIR} ${PC_ATK_INCLUDE_DIRS}
  PATH_SUFFIXES atk-1.0)

FIND_LIBRARY(
  ATK_LIBRARY NAMES atk-1.0
  HINTS ${PC_ATK_LIBDIR} ${PC_ATK_LIBRARY_DIRS})

#
#
#result
#
#
SET(GTK3_LIBRARY_DIRS ${GTK3_LIBRARY} ${GLIB2_LIBRARY} ${PANGO_LIBRARY} ${CAIRO_LIBRARY} ${GDKPIXBUF_LIBRARY} ${ATK_LIBRARY})
SET(GTK3_INCLUDE_DIRS ${GTK3_INCLUDE_DIR} ${GLIB2_INCLUDE_DIR} ${PANGO_INCLUDE_DIR} ${CAIRO_INCLUDE_DIR} ${GDKPIXBUF_INCLUDE_DIR} ${ATK_INCLUDE_DIR})

INCLUDE(FindPackageHandleStandardArgs)

FIND_PACKAGE_HANDLE_STANDARD_ARGS(
  GTK3 DEFAULT_MSG
  GTK3_LIBRARY GTK3_INCLUDE_DIR)

MARK_AS_ADVANCED(GTK3_INCLUDE_DIR GTK3_LIBRARY)

FindGObject.cmake

# - Try to find GObject
# Once done this will define
#
#  GOBJECT_FOUND - system has GObject
#  GOBJECT_INCLUDE_DIR - the GObject include directory
#  GOBJECT_LIBRARIES - the libraries needed to use GObject
#  GOBJECT_DEFINITIONS - Compiler switches required for using GObject

# Copyright (c) 2011, Raphael Kubo da Costa <kubito@gmail.com>
# Copyright (c) 2006, Tim Beaulen <tbscope@gmail.com>
#
# Redistribution and use is allowed according to the terms of the BSD license.
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.

FIND_PACKAGE(PkgConfig)
PKG_CHECK_MODULES(PC_GOBJECT gobject-2.0)
SET(GOBJECT_DEFINITIONS ${PC_GOBJECT_CFLAGS_OTHER})

FIND_PATH(GOBJECT_INCLUDE_DIR gobject.h
   HINTS
   ${PC_GOBJECT_INCLUDEDIR}
   ${PC_GOBJECT_INCLUDE_DIRS}
   PATH_SUFFIXES glib-2.0/gobject/
   )

FIND_LIBRARY(_GObjectLibs NAMES gobject-2.0
   HINTS
   ${PC_GOBJECT_LIBDIR}
   ${PC_GOBJECT_LIBRARY_DIRS}
   )
FIND_LIBRARY(_GModuleLibs NAMES gmodule-2.0
   HINTS
   ${PC_GOBJECT_LIBDIR}
   ${PC_GOBJECT_LIBRARY_DIRS}
   )
FIND_LIBRARY(_GThreadLibs NAMES gthread-2.0
   HINTS
   ${PC_GOBJECT_LIBDIR}
   ${PC_GOBJECT_LIBRARY_DIRS}
   )
FIND_LIBRARY(_GLibs NAMES glib-2.0
   HINTS
   ${PC_GOBJECT_LIBDIR}
   ${PC_GOBJECT_LIBRARY_DIRS}
   )

SET( GOBJECT_LIBRARIES ${_GObjectLibs} ${_GModuleLibs} ${_GThreadLibs} ${_GLibs} )

INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(GOBJECT DEFAULT_MSG GOBJECT_LIBRARIES GOBJECT_INCLUDE_DIR)

MARK_AS_ADVANCED(GOBJECT_INCLUDE_DIR _GObjectLibs _GModuleLibs _GThreadLibs _GLibs)

Dernière modification par grim7reaper (Le 27/01/2012, à 10:03)

---

Blog

Rolinh

Re : /* Topic des codeurs [6] */

Wouao
Je n'en demandais pas tant! Je vais pouvoir comparer avec ce que j'avais commencé à écrire mais apparemment j'étais partit dans la bonne voie (mais n'avait pas encore regardé pour GTK).
Merci beaucoup en tout cas!

Alors si jamais, voilà ce que je cherche à faire (idées sujettes à toutes remarques puisqu'elles sont peut-être nulles):
- pouvoir faire un make cli, make gui ou make all afin de créer le binaire CLI (nommé lcp provisoirement), le binaire GUI (nommé lincopier) ou les deux, respectivement.
- que ces binaires soient générés dans un dossier "bin/BUILDTYPE" à la racine du projet (ouep, je suis du genre maniaque ) où le BUILDTYPE est du genre debug, prod ou devel.
- ne pas foutre le dawa dans l'existant
- make clean et make mrproper afin de faire le nettoyage
- gérer la numérotation de version de LinCopier
- make install avec configuration du prefix (/usr par exemple)

je ne crois pas avoir oublié quelque chose pour le moment. Je vais me pencher avec grande attention sur ce que tu m'as déjà préparé.

EDIT: en regardant, j'ai vu que tu utilisais GTK pour lincopier-cli. En fait, lincopier-cli n'a pas besoin de gtk vu que ça sera un outil grossièrement comparable à cp (sauf que la copie se fait dans une queue et que l'on pourra gérer les erreurs survenues lors de la copie).

EDIT2: comment on peut gérer les flags passés à gcc? J'ai cru comprendre que c'était un truc dans le genre:

add_definitions(-std=c89)

Donc si j'ai bien compris, par exemple pour inclure plus ou moins de flags en fonction de la BUILD choisie, il faudrait faire un truc dans le genre:

if(CMAKE_BUILD_TYPE STREQUAL "GRIM")
  add_definitions(-Wunused-parameter -Wlong-long -Wsign-conversion -Wconversion -Wimplicit-function-declaration)
endif()

ou bien j'ai tout faux là?

Dernière modification par Rolinh (Le 27/01/2012, à 10:32)

grim7reaper

Re : /* Topic des codeurs [6] */

- pouvoir faire un make cli, make gui ou make all afin de créer le binaire CLI (nommé lcp provisoirement), le binaire GUI (nommé lincopier) ou les deux, respectivement.

Tu l’as déjà plus ou moins.
Un simple make construit tout.
Après, tu as une cible par add_executable donc si tu veux un make lcp et un make lincopier il suffit de changer le nom des exécutables dans add_executable.
Si par contre tu veux absolument des noms de règles différents des noms d’exécutables (make cli pour générer lcp et make gui pour générer lincopier), je ne sais pas comment faire pour l’instant, il faut que je cherche.

- que ces binaires soient générés dans un dossier "bin/BUILDTYPE" à la racine du projet (ouep, je suis du genre maniaque ) où le BUILDTYPE est du genre debug, prod ou devel.

Utilise un truc du genre.

set(RUNTIME_OUTPUT_DIRECTORY bin/${CMAKE_BUILD_TYPE})

Par défaut, CMake possède les BUILD_TYPE suivant :
- None ;
- Debug (optimisé pour la vitesse mais en restant debuggable) ;
- Release (optimisé pour la vitesse, pas de d’assert ou de symbole de debug) ;
- RelWithDebInfo (comme le précédent, mais avec symboles de debug) ;
- MinSizeRel (optimise la taille) ;

À voir si ça te suffit où si tu veux d’autres modes (je ne sais pas si on peut en ajouter facilement, en revanche il est très simple de modifier le comportement d’un mode (flag de compil’ utilisé par exemple) via le fichier CMakeCache.txt (ou mieux, via l’interface ncurses ccmake)).

Édit : oui, tu peux en ajouter facilement  :

If you are using the Makefile generator, you can create your own build type like this:
SET(CMAKE_BUILD_TYPE distribution)
SET(CMAKE_CXX_FLAGS_DISTRIBUTION "-O3")
SET(CMAKE_C_FLAGS_DISTRIBUTION "-O3")

- ne pas foutre le dawa dans l'existant

C’est à dire ?
Par défaut, CMake place toute sa merde dans le répertoire CMakeFiles.

- make clean et make mrproper afin de faire le nettoyage

Rien à faire, déjà généré par défaut pour clean (mais il supprime aussi l’exécutable), pas de mrproper.
clean c’est plus ou moins standard dans le monde du Makefile, mrproper absolument pas.
De plus, quand on y réfléchit c’est plus logique d’avoir un clean qui supprime tout au lieu d’un clean pour les objets et un mrproper pour les exécutables car si tu supprimes tout les fichiers objets tu devras de toutes façons recompiler tes exécutables.

- gérer la numérotation de version de LinCopier

C’est à dire ?

- make install avec configuration du prefix (/usr par exemple)

La règle make install est généré automatiquement si tu à mis ce qu’il faut dans le CMakeLists.txt (là aussi faut que je regarde un peu, je n’ai jamais fait d’install pour mes softs vu que ça n’avait pas vraiment de sens pour ce que je faisait)
Le choix du préfixe d’installation se fait à la génération du Makefile.
Par exemple :

cmake -G'Unix Makefiles' -DCMAKE_INSTALL_PREFIX=/usr
make
make install

EDIT: en regardant, j'ai vu que tu utilisais GTK pour lincopier-cli. En fait, lincopier-cli n'a pas besoin de gtk vu que ça sera un outil grossièrement comparable à cp (sauf que la copie se fait dans une queue et que l'on pourra gérer les erreurs survenues lors de la copie).

Bah en faite, dans ton Makefile, tu utilisais gui.c comme dépendance de lincopier-cli donc j’ai mis GTK 3 en dépendance même si ça me semblait bizarre.

EDIT2: comment on peut gérer les flags passés à gcc? J'ai cru comprendre que c'était un truc dans le genre:

add_definitions(-std=c89)

Donc si j'ai bien compris, par exemple pour inclure plus ou moins de flags en fonction de la BUILD choisie, il faudrait faire un truc dans le genre:

if(CMAKE_BUILD_TYPE STREQUAL "GRIM")
  add_definitions(-Wunused-parameter -Wlong-long -Wsign-conversion -Wconversion -Wimplicit-function-declaration)
endif()

ou bien j'ai tout faux là?

C’est une façon de faire, mais une mauvais car tu perds la généricité au niveau du compilateur (et si je veux utiliser clang ? ou icc ?).
Pour reprendre un bout du tuto sur développez dont je t’ai passé le lien :

En bref, ne définissez rien dans CMakeLists.txt qui puisse varier d'un ordinateur à l'autre ou d'un cas d'utilisation à l'autre. Voici quelques exemples d'informations qui ne doivent pas figurer dans le fichier :
- le chemin vers votre compilateur ou tout autre utilitaire participant à la compilation ;
- le chemin vers une bibliothèque tierce ;
- les options de compilation propres au système (optimisation pour une architecture particulière) ou au cas d'utilisation (niveau d'optimisation, présence des symboles de débogage) ;
- le niveau de verbosité des scripts de compilation générés ;
- etc.
Tous ces paramètres personnels doivent être définis ailleurs : dans le fichier CMakeCache.txt.

Donc si tu veux faire ça, passe par CMakeCache.txt (édite le à la main, ou mieux utilise ccmake). Comme ça ta config reste locale à toi, si moi je préfère compiler ton soft avec un autre compilo ou d’autres options je peux le faire sans toucher à ta config.

Dernière modification par grim7reaper (Le 27/01/2012, à 11:06)

---

Blog

Rolinh

Re : /* Topic des codeurs [6] */

Tu l’as déjà plus ou moins.
Un simple make construit tout.

Oui mais l'idée serait de pouvoir construire l'exécutable cli sans avoir à se farcir les dépendances GTK.

Après, tu as une cible par add_executable donc si tu veux un make lcp et un make lincopier il suffit de changer le nom des exécutables dans add_executable.
Si par contre tu veux absolument des noms de règles différents des noms d’exécutables (make cli pour générer lcp et make gui pour générer lincopier), je ne sais pas comment faire pour l’instant, il faut que je cherche.

Étant donné ma remarque ci-dessus, je vais chercher comment faire ça.

Utilise un truc du genre.

set(RUNTIME_OUTPUT_DIRECTORY bin/${CMAKE_BUILD_TYPE})

Je crois que c'est

set(EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})

plutôt non?

Par défaut, CMake place toute sa merde dans le répertoire CMakeFiles.

Oui, c'est vrai. Par exemple, je vais voir si ce ne serait pas mieux de mettre le CMakeModules ailleurs que dans src.

Rien à faire, déjà généré par défaut pour clean (mais il supprime aussi l’exécutable), pas de mrproper.
clean c’est plus ou moins standard dans le monde du Makefile, mrproper absolument pas.
De plus, quand on y réfléchit c’est plus logique d’avoir un clean qui supprime tout au lieu d’un clean pour les objets et un mrproper pour les exécutables car si tu supprimes tout les fichiers objets tu devras de toutes façons recompiler tes exécutables.

Tu as parfaitement raison.

- gérer la numérotation de version de LinCopier

C’est à dire ?

Un truc dans ce genre là:

set (LinCopier_VERSION_MAJOR 0)
set (LinCopier_VERSION_MINOR 1)

Avec ce qu'il faut dans le code source pour le gérer. Enfin, je ne sais pas si c'est la meilleure façon de faire.

Bah en faite, dans ton Makefile, tu utilisais gui.c comme dépendance de lincopier-cli donc j’ai mis GTK 3 en dépendance même si ça me semblait bizarre.

Ouais, c'est une erreur de conception. Suite à mes modifs de hier ça devrait être corrigé puisque main-cli ne devrait absolument pas dépendre de gui.c.

C’est une façon de faire, mais une mauvais car tu perds la généricité au niveau du compilateur (et si je veux utiliser clang ? ou icc ?).
(...)
Donc si tu veux faire ça, passe par CMakeCache.txt (édite le à la main, ou mieux utilise ccmake). Comme ça ta config reste locale à toi, si moi je préfère compiler ton soft avec un autre compilo ou d’autres options je peux le faire sans toucher à ta config.

Ok. Merci pour la précision. Je vais regarder ce ccmake alors.

grim7reaper

Re : /* Topic des codeurs [6] */

Tu l’as déjà plus ou moins.
Un simple make construit tout.

Oui mais l'idée serait de pouvoir construire l'exécutable cli sans avoir à se farcir les dépendances GTK.

Bah tu demandais aussi un make all
Je te dis juste que make tout court peut être équivalent à make all
Après, tu peux aussi faire un truc à base d’option. Extrait de CMakeLists.txt sur un de mes codes :

# Viewer.
option(GRAPHIC_VIEWER "Compile the viewer (SDL needed)?" off)

if(GRAPHIC_VIEWER)

    include(FindSDL)

    find_package(SDL REQUIRED)

    list(APPEND include_directories ${SDL_INCLUDE_DIR})

    add_executable(viewer
    "src/event.c"
    "src/viewer.c"
    "src/maze.c"
    "src/display.c"
    "src/tools.c"
    )

    target_link_libraries(viewer ${SDL_LIBRARY})

endif(GRAPHIC_VIEWER)

Je pense que ça peux assez bien s'adapter à ton cas.
Par défaut, tu compiles juste lcp (donc pas besoin de dépendances à GTK 3) avec un make.
Après, si un gus veut la version graphique, il l’active (via ccmake ou la ligne de commande) et du coup là tu ajoutes les dépendances à GTK 3 (donc vérification de sa présence) et tu ajoutes la compilation de la version graphique lincopier. Un simple make construira les deux.
Et si tu peux pouvoir désactiver le version CLI, tu peux faire une option pour elle aussi.

Utilise un truc du genre.

set(RUNTIME_OUTPUT_DIRECTORY bin/${CMAKE_BUILD_TYPE})

Je crois que c'est

set(EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})

plutôt non?

Non, ça c’est déprécié (mais beaucoup de tuto sur Internet ne sont pas à jour).

       EXECUTABLE_OUTPUT_PATH
              Old executable location variable.

              The target property RUNTIME_OUTPUT_DIRECTORY supercedes this variable for a target if it is set.  Executable targets are otherwise placed in this directory.

Par défaut, CMake place toute sa merde dans le répertoire CMakeFiles.

Oui, c'est vrai. Par exemple, je vais voir si ce ne serait pas mieux de mettre le CMakeModules ailleurs que dans src.

Oui, dans src ça fait tâche.
J’avais juste fait comme ça hier à l’arrache, mais oui il vaudrait mieux le déplacer.

- gérer la numérotation de version de LinCopier

C’est à dire ?

Un truc dans ce genre là:

set (LinCopier_VERSION_MAJOR 0)
set (LinCopier_VERSION_MINOR 1)

Avec ce qu'il faut dans le code source pour le gérer. Enfin, je ne sais pas si c'est la meilleure façon de faire.

Ça me paraît pas trop mal.
Il y a un truc qui te gène là dedans ?

Dernière modification par grim7reaper (Le 27/01/2012, à 12:33)

---

Blog

Rolinh

Re : /* Topic des codeurs [6] */

Je pense que ça peux assez bien s'adapter à ton cas.
Par défaut, tu compiles juste lcp (donc pas besoin de dépendances à GTK 3) avec un make.
Après, si un gus veut la version graphique, il l’active (via ccmake ou la ligne de commande) et du coup là tu ajoutes les dépendances à GTK 3 (donc vérification de sa présence) et tu ajoutes la compilation de la version graphique lincopier. Un simple make construira les deux.
Et si tu peux pouvoir désactiver le version CLI, tu peux faire une option pour elle aussi.

Merci, c'est exactement ce que je cherchais à faire.

Et merci pour les autres précisions.

EDIT: j'ai vu ton edit après coup ^^

Il y a un truc qui te gène là dedans ?

Non, c'est juste que je ne sais pas si ça ne gère que des chiffres. Par exemple, la version "trunk" , la version 0.1-alpha2, etc. Et en fait, après avoir bien réfléchi, il faudrait que j'ajoute une version de patch (0.1.2 par exemple).

Dernière modification par Rolinh (Le 27/01/2012, à 12:37)

grim7reaper

Re : /* Topic des codeurs [6] */

Il y a un truc qui te gène là dedans ?

Non, c'est juste que je ne sais pas si ça ne gère que des chiffres. Par exemple, la version "trunk" , la version 0.1-alpha2, etc. Et en fait, après avoir bien réfléchi, il faudrait que j'ajoute une version de patch (0.1.2 par exemple).

Il semblerai que ça ne gère que les chiffres.
Mais ce n’est pas un soucis vu que tu peux créer tes propres variables.
Du genre (encore un extrait de chez moi) :

set(VERSION "\"trunk\"")
set(PATCH 2)

configure_file(
    ${PROJECT_SOURCE_DIR}/config.h.in
    ${PROJECT_SOURCE_DIR}/config.h
)

Et dans config.h.in (vu que toi tu as déjà un extern.h tu peux utiliser extern.h.in au lieu de config.h.in si tu veux et générer un extern.h au lieu de config.h, de même je met .in pour le fichier de base mais tu peux mettre .cmake ou ce que tu veux).

#ifndef H_CONFIG_LS_20120127124725 
#define H_CONFIG_LS_20120127124725 

#cmakedefine VERSION @VERSION@
#cmakedefine PATCH @PATCH@
 
#endif /* H_CONFIG_LS_20120127124725 */ 

Résultat (le config.h généré) :

#ifndef H_CONFIG_LS_20120127124725 
#define H_CONFIG_LS_20120127124725 

#define VERSION "trunk"
#define PATCH 2

#endif /* H_CONFIG_LS_20120127124725 */ 

Dernière modification par grim7reaper (Le 27/01/2012, à 12:54)

---

Blog

Rolinh

Re : /* Topic des codeurs [6] */

Nickel
Merci beaucoup, encore une fois.

Rolinh

Re : /* Topic des codeurs [6] */

Simple question, si le dossier bin, où j'aimerais que les exécutables soient placés, n'existe pas, cmake va-t-il les créer ou bien faut-il que je fasse une règle pour ça?

grim7reaper

Re : /* Topic des codeurs [6] */

Pour l’installation ?
Oui je pense qu’il le crée, mais à vérifier.

---

Blog

Rolinh

Re : /* Topic des codeurs [6] */

non, pas pour l'installation, pour le make. Étant donné que je souhaite quand je fasse make, les binaires soient générés dans bin directement. C'est en rapport à cette ligne:

set(RUNTIME_OUTPUT_DIRECTORY bin/${CMAKE_BUILD_TYPE})

grim7reaper

Re : /* Topic des codeurs [6] */

Je ne sais plus, (par contre avec EXECUTABLE_OUTPUT_PATH il le créait lorsque tu générais le Makefile )
Bon, en même temps tu choisis l’arborescence de ton projet et tu écris le fichier CMakeLists.txt donc normalement tu t’arranges pour être cohérent.
Au pire, s’il ne le fait pas, tu peux faire un truc du genre :

set(RUNTIME_OUTPUT_DIRECTORY "bin")

if(NOT EXISTS "bin" OR NOT IS_DIRECTORY "bin")
    file(MAKE_DIRECTORY "bin")
endif(NOT EXISTS "bin" OR NOT IS_DIRECTORY "bin")

Édit : Hum, au passage je viens de me rendre compte d’un truc : je crois que c’est CMAKE_RUNTIME_OUTPUT_DIRECTORY qu’il faut utiliser, pas RUNTIME_OUTPUT_DIRECTORY (ça c’est une propriété, pas une variable).
Et dans ce cas, oui, il s’en charge.

Dernière modification par grim7reaper (Le 27/01/2012, à 18:29)

---

Blog