DreamTech share experiences with git and cmake jesnault 04-10-12

DREAM-Tech
Combinaison des outils GIT et CMake pour des projets C++
SERVICE : DREAM
Jérôme esnault
Sophia-Antipolis 04 Octobre 2012

SOMMAIRE
1. SCM tool GIT, créer et gérer vos projets
2. Build tool CMake, créer et gérer vos projets
3. CMakeTools, submodule GIT de vos projets
jerome.esnault@inria.fr 04 Octobre 2012 - 2

1
SCM tool GIT, créer et gérer vos projets
1.1 Présentation, collaborer autour d’un dépôt centralisé
1.2 Manipulations d’un dépôt GIT (local/distant)
1.3 Collaboration avec SVN
1.4 Les submodules GIT

1.1 Présentation, collaborer autour d’un dépôt « centralisé »
• Source Code Management : GIT
• Objectif : Stocker la chronologie des modifications effectuées sur un ensemble
de fichiers
• Gestion de version décentralisée (tout le monde a potentiellement la dernière
version des sources du projet)
• Gestion des branches et des conflits
• Développé depuis 2005 par Linus Torvalds (et son équipe)

• HEAD (référence vers le dernier commit de la branche courante)
• Les fichiers description et config (la config de GIT propre à ce projet, voir
.gitconfig pour la configuration globale)
• L’index contient tous les changements du répertoire de travail prêt à être
commités sur le dépôt local.
• Les hooks (sont les scripts pre/post opération git sur le dépôt)
• logs contient l’historique de la branche courante
• Le répertoire objects contient les objets GIT (commits, tag, tree, blob)
• ref/head/* et ref/remotes/* sont des références sur des commits des branches
locales et distantes

Snapshot Identification de chaque objet
04 Octobre 2012 - 6
Historique
Répertoire
Fichier
GIT par SHA-1 hash

Installation
Création :
git init git init --bare
LOCAL DISTANT

• INSTALLATION
• UNIX: yum ou apt-get
$ sudo yum search git
$ sudo yum install git-core
$ sudo yum install git-doc
$ git config --global user.name « TonNom TonPrenom »
$ git config --global user.email TonPrenom.TonNom@domain.com
$ git config --global color.ui auto #gestion des couleurs dans le terminal
• WINDOWS:
• Installer msysgit
• Installer tortoiseGIT avec le client SSH PLink (Putty)
• Installer Putty, PuttyGen et Pageant
• Créer votre clé SSH2 RSA avec PuttyGen
• Ou convertir votre clé id_rsa linux en .ppk
• Utiliser Pageant pour ajouter votre clé
OU
• Utiliser smartGit
OU
• Utiliser cygwin

• Création d’un dépôt GIT distant vierge :
Server $ cd /gitroot/cmaketools && mkdir dreamtech.git && cd drematech.git
Server $ git init --bare
• Rapatriement d’un dépôt GIT public distant (push non possible) :
Local $ git clone git://scm.gforge.inria.fr/cmaketools/dreamtech.git
Local $ cd dreamtech
Local $ git status
• Autorisation de push :
1. Ajouter clé privée SSH sur le serveur et autoriser l’accès au projet
2. Enregistrer le lien SSH vers le dépôt du projet :
Local $ git remote add dreamtech-dev
git+ssh://userName@scm.gforge.inria.fr//gitroot/cmaketools/dreamtech.git
Local $ git remote -v show
…DO MODIFICATIONS…
Local $ git push dreamtech-dev master
Local $ git remote rm dreamtech-dev # to remove this « private » remote

• Complétion et prompt GIT : télécharger git-completion.bash
.bashrc ou .profile file
source ~/git-completion.bash
export GIT_PS1_SHOWDIRTYSTATE=1
export GIT_PS1_SHOWSTASHSTATE=1
export GIT_PS1_SHOWUNTRACKEDFILES=1
export PS1='u@H:w$(__git_ps1 " (%s) ")$n '
(+) index non vide
(*) working tree modifié
($) pile GIT non vide
(%) fichier(s) non tracké
• Outils de diff/merge (meld doit être installé)
• command git-meld
• script git-meld.wrap : (here the diff cmd overwrite the merge cmd)
$ echo ‘#!/bin/bash’ > ~/git-meld.wrap
$ echo ‘meld $2 $5’ >> ~/git-meld.wrap
$ chmod a+rx ~/git-meld.wrap
$ git config --global diff.external ~/git-meld.wrap
$ git config --global difftool.prompt false
$ git config --global difftool.meld.cmd exec meld $LOCAL $MERGED $REMOTE

• Spécifier son propre éditeur dans GIT (gedit for example):
$ git config --global core.editor gedit
• Gérer ses propres aliases de commandes GIT :
.gitconfig ou .git/config file
[alias]
undo = reset --mixed HEAD^ # cancel the last local commit
sub = submodule update --init --recursive # get/update all submodules
svnpull = svn rebase
svnpush = svn dcommit
# Show all the commits a specific author has done
author = "!sh -c 'git log --tags --source --graph --oneline --author="$1"' –"
• Ignorer certains fichiers sous les répertoires du projet GIT
$ echo ‘*~’ > .gitignore
$ echo ‘*.orig’ >> .gitignore
…

• Travailler en local :
• Avec des branches :
$ git branch -r # to see all your local an remote branches
$ git checkout –t origin/htmlGitDoc #create local branch based&tracked on remote one
… DO MODIFICATION ONTO SOURCE FILES OF htmlGitDoc branch…
$ git add path/to/add/to/index/to/prepare/the/next/commit/on/this/branch
$ git commit –m «Message describing the changes induced by this commit»
git commit
–m «msg»
c4
c2
c1
c4
c3
c1
c5
c2
htmlGitDoc master htmlGitDoc htmlGitDoc master
DEPOT DISTANT :
origin (default remote)
DEPOT LOCAL :
Master (default branch)
REPERTOIRE DE TRAVAIL
c6
c3
c5
c1
c6
c2
c5
git checkout -t
origin/htmlGitDoc
git add
path
index

$ git branch myGitDoc # create a new branch based on the current htmlGitDoc branch
$ git branch # to see all your local branches
$ git checkout myGitDoc # switch to this new another myGitDoc branch
… DO MODIFICATION ONTO SOURCE FILES OF myGitDoc branch…
$ git add path/to/add/to/index/to/prepare/the/next/commit/on/this/branch
$ git branch –m myGitDoc gitDoc # rename the branch
$ git commit –m «Message describing the changes induced by this commit»
c4
c2
c5
c4
c3
gitDoc
c1 c1
myGitDoc master htmlGitDoc htmlGitDoc master
c6
c3
c5
c2
c6
c2
c5
c7
git add git commit –m «msg»
path
index c7
myGitDoc
gitDoc
c1

• Travailler en local et mise à jour distante :
$ git checkout master # switch to default master branch
$ git merge gitDoc # merge htmlGitDoc branch into gitDoc branch
$ git branch –d gitDoc # remove the unless local gitDoc
$ git branch –d –r origin/htmlGitDoc # remove the unless remote tracked htmlGitDoc
$ git push --delete origin htmlGitDoc # delete distant branch
# can use also : git push origin :htmlGitDoc (pushing nothing correspond to delete)
c8
c4
c2
c4
c3
git merge gitDoc
Git push origin master
master htmlGitDoc htmlGitDoc master
index
c4
c3
c5
c3
c2
c6
c2
c5
c8
c7
master gitDoc
c8
Git push --delete
origin htmlGitDoc
c1 c1
c1

• Gérer les conflits
… DO MODIFICATION ONTO SOURCE FILES …
…MERGE CONFLICTS…
$ git mergetool # in our case launch meld for each file in conflict :
# with REMOTE version file to left window and LOCAL version file to right window
# then you can dynamicly change the MERGED version file (on the middle)
$ git merge --abort # cancel the command causing the conflict management
# OR
$ git rebase --continue#if the conflict to manage is caused by a rebase, apply next patch
$ git rebase --abort # if the conflict to manage is caused by a rebase
• Changer sa structure de fichier (« jouer » avec l’index)
$ mkdir doc
$ git mv *.htm doc/
$ git rm testFile
$ git commit –am « Change the emplacement of the .htm files to the doc/ dir »

• Gérer les annulations
$ git commit --am « BIG UGLY NO TESTED (BUILD) COMMIT »
… OOPS I JUST REALIZE MY STUPIDITY…
$ git reset HEAD^ # HEAD is the last commit of the current branch, ^ is its first parent
# can also use HEAD~3 (to reset 3 commit before the last of the current branch)
# can also use a specific SHA commit
$ git checkout path # my modif is really poor, I want to restore it from the last record
c3
c2
c3
c2
Git commit --am « … »
Restore path to c2 state
Git checkout path
Git reset HEAD^
Return to a dirty working dir
c1 c1 c1
master master
c2
c3
master
index
REPERTOIRE DE TRAVAIL DEPOT LOCAL DEPOT DISTANT

$ git reset --hard HEAD^ # restore from the last record and overwrite all
c3
c2
c3
c2
Git commit --am « … »
Git reset –hard HEAD^
c1 c1 c1
master master
c3
c2
master
index

Git revert HEAD^
c4 c4
c3
Git push origin master
Git commit --am « … » Git push origin master
c2
c4
c3
master master
c3
c2
c2
$ git push origin master
$ git revert HEAD^ # commit the inverse diff of the previous commit
master
index
c1 c1 c1

• Avec la pile :
… DO MODIFICATION ONTO SOURCE FILES OF myGitDoc branch…
$ git stash # save the dirty working dir (all modified files) in stash@{i++} (i start to 0)
$ git pull origin master # do something with your working directory
$ git stash pop # restore your change saved previously in the stash{0}
$ git stash clear # clean up all the stash if still elements
c3
c2
c1
master
Git pull origin master
c3
c2
c1
master
REPERTOIRE DE TRAVAIL DEPOT LOCAL
stash@{0}
c4
c3
c2
c1
master
.
.
.
DEPOT DISTANT
c4 c4
Stash

• Avec la pile, ne stocker qu’un fichier modifié dans la pile :
$ git add <files you want to keep in the modified list>
# to stock temporary in the index files you want to keep
$ git stash save –keep-index
# at this time your remain modified file you want to stash is stacked
$ git rm --cached <files you want to keep in the modified list>
# to restore your working dir from index
c2
c1
master
REPERTOIRE DE TRAVAIL
Stash
stash@{0}
.
.
.
git add path1 path2
Index
path1
path2
file Git rm –cached
path1 path2

• Travailler en local (bonnes pratiques) :
• Avec un historique linéaire :
$ git add someModifiedFiles
$ git commit -m «commit msg c2b»
$ git commit -am «commit msg c3b» # add all remain dirty files to index and commit
… IN THE SAME TIME THERE HAD THE C2 COMMIT (FROM ANOTHER USER)…
$ git pull --rebase origin master #apply my local commits above the last remote commi
c3b
c2b
c2b
Apply patch
Store patch
c1 temporary area
master
c3b
c2b
c1
master
c3b
c3b
c2b
c2
c2
c1
« Git fetch »
master
Ancêtre
commun
DEPOT DISTANT

• Travailler en local (bonne pratique) et mise à jour distante :
• Avec un historique linéaire :
$ git add someModifiedFiles
$ git commit -m «commit msg c2b»
$ git commit -am «commit msg c3b» # add all remain dirty files to index and commit
… IN THE SAME TIME THERE HAD THE C2 COMMIT (FROM ANOTHER USER)…
$ git pull --rebase origin master #apply my local commits above the last remote commit
c4
c3
c2
c1
master
c4
c3
c2
c1
master
git push origin master
c3b SHA != c3 SHA
c2b SHA != c2 SHA
c4
c3
c2
c1
master
DEPOT DISTANT

• Avec le TAG:
# create a git object TAG named v0.1 pointing to the last commit of this branch
$ git tag –a v0.1 –m « tag description msg » HEAD
$ git commit –am « add tag v0.1»
$ git push --tags origin master
$ git tag –d v0.1 # to delete a tag
c4
c3
c2
c1
master
c4
c3
c2
c1
master
V0.1 c4 V0.1
c3
c2
c1
master
DEPOT DISTANT

• Gérer le réarchitecturage de son historique:
• le rebase interactif : Splitter un commit en 2
ATTENTION:
réécriture de l’historique = divergence avec l’historique du dépôt distant
$ git rebase -i HEAD^ #f rom HEAD
# replace ‘pick’ keyword by ‘edit’ keyword for a particular commit ID, save and close
#undo the parent commit to clean index & local repo and restore the working dir
$ git reset HEAD^
#DO WORK. here you work on the commit ID specified by the rebase cmd
$ git add modification1 && git commit –m “msg commit modification 1”
#DO WORK.
$ git add modification2 && git commit –m “msg commit modification 2”
git rebase –continue #validation to continue rebase opertations
sha c3
Dirty WD
sha c2 c2
sha c2b sha c2
c1
master
c3 c3
c2b c2
c1
master
sha c3
c2b sha c2b

• Gérer le réarchitecturage de son historique:
• le rebase interactif : regrouper 2 commits en 1
ATTENTION:
réécriture de l’historique = divergence avec l’historique du dépôt distant
$ git rebase -i HEAD~3 #from HEAD to 3 commit ancestor
# replace ‘pick’ keyword by ‘squash’ keyword for a commit ID, save and close file
# All commits mark as squash will be encapsulate into the ancestor mark as pick
# edit the commit message if necessary
git rebase –continue #validation to continue rebase opertations
c3 c3
sha c3
sha c3
sha c2 c2
sha c2b sha c2
c1
master
c2b c2
c1
master
c2b sha c2b

• Gestion avec copie conforme dans une branche GIT :
git init | git clone …
git svn init svnUrlServer/project -T trunk/projectTrunkDirectory
• récupération depuis SVN
Repo GIT :
branch master
Repo SVN: trunk
Repo GIT :
branch master
Repo GIT :
branch master
git svn fetch
.svn
dépôt : Distant
git svn rebase dépôt : Local
répertoire de travail
GATE KEEPER GIT/SVN

• copie du dépôt SVN sous la branche master
Repo GIT :
branch master
Repo SVN: trunk
git push
Repo GIT :
branch master
dépôt : Distant
git commit dépôt : Local
Repo GIT :
branch master
.svn
répertoire de travail
GATE KEEPER GIT/SVN

• récupération du dépôt GIT (copie du dépôt SVN)
Repo GIT :
branch master
Repo SVN: trunk
Repo GIT :
branch master
Repo GIT :
branch master
.svn
dépôt : Distant
dépôt : Local
répertoire de
travail
git pull
Repo GIT :
branch master
Repo GIT :
branch master
USER DEV GIT GATE KEEPER GIT/SVN

• actualisation du dépôt GIT (copie modifiée du dépôt SVN)
Repo GIT :
branch master
Repo SVN: trunk
Repo GIT :
branch master
Repo GIT :
branch master
.svn
dépôt : Distant
dépôt : Local
répertoire de
travail
git push
Repo GIT :
branch master
git commit
Repo GIT :
branch master

• récupération du dépôt GIT (copie modifiée du dépôt SVN)
Repo GIT :
branch master
Repo SVN: trunk
Repo GIT :
branch master
git pull --rebase
Repo GIT :
branch master
.svn
dépôt : Distant
dépôt : Local
répertoire de
travail
Repo GIT :
branch master
Repo GIT :
branch master

• actualisation du dépôt GIT depuis le dépôt SVN
Repo GIT :
branch master
Repo GIT :
branch master
Repo GIT :
branch master
Repo SVN: trunk
dépôt : Distant
dépôt : Local
répertoire de
travail
Repo GIT :
branch master
Repo GIT :
branch master
git svn fetch
.svn
git svn rebase

• actualisation du dépôt SVN depuis le dépôt GIT
Repo GIT :
branch master
git svn dcommit
Repo GIT :
branch master
Repo GIT :
branch master
Repo SVN: trunk
dépôt : Distant
dépôt : Local
répertoire de
travail
Repo GIT :
branch master
Repo GIT :
branch master
.svn

• actualisation du dépôt GIT (distant) depuis le dépôt GIT (local)
Repo GIT :
branch master
Repo SVN: trunk
git push -f
Repo GIT :
branch master
git commit
Repo GIT :
branch master
.svn
dépôt : Distant
dépôt : Local
répertoire de
travail
Repo GIT :
branch master
Repo GIT :
branch master

• mise à jour en utilisant le merge :
=> 1 commit unique de merge (ugly)
=> perte de l’historique
=> impossibilité de mettre à jour dans l’autre sens
• mise à jour en utilisant le rebase :
=> Conservation de l’ensemble de l’historique
=> Réorganisation linéaire des commits
=> Possibilité de mettre à jour dans les deux sens
Problème :
Et pour les autres développeurs qui pull et push sur la branche master ?
Comment se mettent-ils à jour après la réécriture de l’historique faite
par le « gate-keeper »?
Leur historique de commit (SHA) en local ne correspond plus à
l’historique distant réécrit par le rebase !
$git reset --hard origin/master

1.3 Les submodules GIT
… ON MY MACHINE : IN MY PROJECT I CREATE A SUBMODULE LINK…
# create a .gitmodule containing the other git project link
$ git submodule add gitUrlServer/project.git
$ git commit –am «add submodule project.git for this project pointing its current HEAD»
… ON ANOTHER MACHINE : IN MY PROJECT I GET SUBMODULES…
$ git submodule update --init
(public) https (prive) ssh
myProject.git
Submodule
project.git
Commit 8g2t
Projet_N.git
Submodule
project.git
Commit tu4f
DISTANT
LOCAL
Project.git
myProject.git Projet_N.git

• Autres fonctionnalités GIT :
• bisect
• cherry-pick
• …
• Workflows ==========
• Git cheat sheet and HERE

2
Build tool CMake, créer et gérer
vos projets
2.1 Présentation et exemple simple
2.2 Super-Projet et ses sous projets

• Objectif: Boite à outils multiplateformes d’aide à la création/compilation de projets C++
• Usage: langage scriptural hautement configurable
• Génération: fichiers utilisable pour les outils de compilation
• Développé: par KitWare en open source
• Démarrer en 1999 pour ITK et ensuite utiliser par VTK
• Actuellement à la version 2.8.9 et utilisé principalement par OGRE, OpenSceneGraph…
CMake / Ctest / CPack
CMake / Ctest / CPack
Modules
CMake
[*.cmake]
[*.in]
Sources C/C++/Java CMakeLists.txt / Ctest scripts
CMakeCache.txt
Native build system files [MakeFiles, sln…]
Targets [executables, libraries, plugins]

Cmake [options] <path-to-source>
$ cd projectName
$ mkdir build && cd build
$ cmake ..
$ make install
$ cd projectName
$ mkdir build && cd build
$ cmake-gui ..
$ make install
Generators / IDE compatibilités :
• Borland
• MinGW
• Nmake
• Unix
• Visual Studio 6/7/8/9/10/11
• Xcode
• codeBlocks
• Eclipse
• QtCreator
Gestion de 3 arborescences :
• CMAKE_SOURCE_DIR
• CMAKE_BUILD_DIR
• CMAKE_INSTALL_PREFIX
CMake_Useful_Variables
CMake_Wiki

Les instructions CMake permettent d’agir sur :
• La création de nouveau projet et sous projets
• La création de variables cmake et de liste de variables
• La manipulation du système de fichier
• La compilation out of source, l’installation et le packaging
• La recherche « automatique » de package de
dépendances et de fichiers
• La création de fonctions et macros
• La personnalisation des propriétés sur les targets
ou le système de fichier
Project(…)
Add_subdirectory(…)
Add_dependencies(…)
Include_directories(…)
Target_link_libraries(…)
Set(…) – unset(…)
List(…)
Option(…)
Foreach() … endforeach()
If() … else() … endif()
File(…) - String(…)
Configure_file(…)
Install(…)
Find_package(…)
Find_library(…)
Find_file(…) – Find_path(…)
Include(…)
Function()…endfunction()
Macro()…endmacro()
Add_definition(…)
Define_property(…)

2.2 Super-Projet et ses sous projets
• A chaque niveau de repertoire dans la hierarchie il y a un CMakeLists.txt
• add_subirectory( <dirName> ) permet à cmake de passer dans le CMakeLists.txt
• Le scope des variables cmake correspond à la visibilité des sous repertoires de la
hierarchie.
• project(<projectname> [languageNameList])
• Un pour le “top root” CMakeLists.txt (super-project Name)
• Les autres dans les sous repertoires sont des sous-projets
• Dans un projet vous pouvez créer vos targets :
• add_library( < targetName > <sourcesList> [STATIC | SHARED]) => for libraries
• add_library( < targetName > <sourcesList> [MODULE]) => for plugins
• add_executable ( < targetName > <sourceList>) => for executables
• les dependences de ces targets peuvent être ajoutées avec :
• target_link_libraries ( <targetName> [itemList] [debug|optimized])
targetName peut être une autre target d’un sous projet (interdependence) ou le
chemin vers une 3rdParty lib
• include_directories([AFTER|BEFORE] dir1 dir2 ...)

3
CMakeTools, submodule GIT de
vos projets
3.2 Fonctionnalités proposées et documentation
3.3 Ouvertures

• Objectif: Mutualiser des utilitaires/ressources CMake de hauts niveaux
$ git clone myProject.git --recursive # to auto get all submodules
#OR (use the <…> macro )
$ cmake .. # cmake will auto find git and check the submodule
(public) https (prive) ssh
myProject.git
Submodule
Cmaketools.git
Commit 8g2t
Projet_N.git
Submodule
Cmaketools.git
Commit tu4f
DISTANT
LOCAL
Cmaketools.git
myProject.git Projet_N.git
Cmaketools.git

cmake_minimum_required(VERSION 2.8)
project(YOUR_PROJECT_TREE)
list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake"
"${CMAKE_SOURCE_DIR}/cmaketools/finders")
"${CMAKE_SOURCE_DIR}/cmaketools/macros")
"${CMAKE_SOURCE_DIR}/cmaketools/projectUtilities")
#add your options, resolve dependencies and add_definitions here
find_package( <PACKAGE> )
add_definitions(-DHAS_<PACKAGE>)
#here we start to use our macros
include(project_tools)
project_init(${CMAKE_PROJECT_NAME} 0 5 0 RPATH true EXPORT myProject)
include_directories( ${CMAKE_SOURCE_DIR}/src/libs
${CMAKE_BINARY_DIR}/include ) #to use *Export.h in your code
add_subdirectory(src) #cmake enter and process in all sub-dir => sub-project
project_export(${CMAKE_PROJECT_NAME} <YOUR_PACKAGE_NAME>
<YOUR_LOWER_CASE_PACKAGE_NAME>-config.cmake)

project_add(<YOUR_SUBPROJECT> LIBS VERBOSE)
list(APPEND ${PROJECT_NAME}_HEADERS <YOUR_HEADERS>)
list(APPEND ${PROJECT_NAME}_HEADERS <YOUR_SOURCES>)
add_library(<YOUR_TARGET, generaly ${PROJECT_NAME}>
${${PROJECT_NAME}_HEADERS}
${${PROJECT_NAME}_SOURCES} )
target_link_libraries(<YOUR_TARGET, generaly ${PROJECT_NAME}>
<PATH_FILE_LIB FOUND ABOVE> )
project_install(${PROJECT_NAME} <YOUR_TARGET, generaly ${PROJECT_NAME}>)

3.2 Fonctionnalités proposées et documentation
• Concentration et mutualisation des modules Find*.cmake non embarqués dans cmake
• Gère la récupération de vos submodules GIT
• L’ajout conditionnel de sous répertoire selon des options et dépendances trouvés
• Des fonctions utilitaires sur le système de fichier (is_empty, list_subdirectories…)
• La gestion de Cpack (centralisé pour toutes les plateformes)
• La génération automatique de fichiers cmake d’export de votre projet pour les projet
l’utilisant comme dépendance (plus besoin de maintenir un module Find*.cmake)
• La désinstallation avec make uninstall
• L’installation sur cluster avec make install-cluster
• CMakeTools s’auto documente avec make install docs
cmake parse une liste de fichiers (par défaut les *.cmake) et cherche les FLAG de
documentation de vos fichiers/fonctions/macros pour créer un fichier cmake.dox qui
sera inclut dans la documentation doxygen.

3.3 Ouvertures
• Le système de récupération automatique des 3rdParty :

DreamTech share experiences with git and cmake jesnault 04-10-12

DreamTech share experiences with git and cmake jesnault 04-10-12

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Último

Último (15)

DreamTech share experiences with git and cmake jesnault 04-10-12