Discussion :

[YvesF]

Bonjour.

J'ai un problème avec un client qui a de grosses applis mal maîtrisées en C++, écrites avec différentes versions de Borland (1, 4 et 5). Comme je ne connais pas du tout les outils existant dans ce domaine je viens poser la question ici...

Son problème est qu'il doit générer des .exe, .dll ou autres d'un volume minimal en cas d'évolutions. Or, si par exemple un .h est touché, tous les fichiers déclarant cet include vont être recompilés, même s'ils ne sont pas vraiment impactés par la modif: par exemple une constante change, mais seuls deux des 5 sources incluant le .h correspondant utilisent cette constante. Dans un tel cas tout sera pourtant recompilé.

Je cherche donc un outil permettant d'expertiser les sources de deux versions différentes de son appli et d'identifier ce qui doit réellement être regénéré, c'est à dire de mesurer les impacts par anayse du code et non pas des dates de mise à jour. Ou tout autre raisonnement d'ailleurs, le but final étant d'obtenir le strict minimum nécessaire à la mise à jour d'un poste.
Et difficulté complémentaire: pas question de toucher le service études en proposant un nouvel IDE, une modif de méthode de travail ou autre, ce serait trop simple.

Actuellement ils font ça de manière assez manuelle grace à SVN qui liste ce qui a été touché, et interview des programmeurs pour savoir ce qu'ils doivent vraiment recompiler. Le temps total de travail se chiffre en jours pour fabriquer une version...

Donc si vous avez l'outil miracle, un truc peut-être du genre JDetect ou mieux encore...

Merci d'avance pour toute aide apportée.

[souviron34]

si tu es sous unixoide (je ne sais pas si ça a été porté sous cygwin), il y a gmake (GnuMake), et même make tout seul, pour peu que tu n'aies pas détruit les .o, il ne recompile que les .c qui ont été modifiés, ou ceux dont les dépendances indiquent un include qui ,lui , a été modifé...

[aoyou]

ou ceux dont les dépendances indiquent un include qui ,lui , a été modifé...

Justement, il aimerait que tous ces fichiers ne soient pas recompilés mais uniquement ceux qui ont été réellement touchés par la modification de l'include. make ne connaissant pas l'historique des modifications, il ne peut se baser que sur la date pour savoir quels fichiers regénérer mais il en regénére certains qui ne sont pas forcément nécessaires effectivement.

Pour éviter les regénérations inutiles, on peut user des pré-déclarations de classe (quand c'est possible).

Si tu trouves un tel outil, ne nous oublie pas.

[YvesF]

En effet, le make ne peut suffire, il faut aller plus loin c'est à dire jusqu'au code. En fait un tel outil, s'il existe, doit forcément se baser sur l'analyse de deux versions différentes d'une même application, lister les écarts, et pour chaque écart rencontré analyser les modules impactés.

A priori sur le plan théorique je ne vois pas d'obstacle. C'est pourquoi je me dis que ca existe peut-être...

[souviron34]

Ben si dans le Makefile tu as mis les dépendances correctement, ça ne re-générera QUE les fichiers touchés....

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
 
 
tout: all
 
 
##SHELL=/bin/csh
 
 
#---------------------------------------------------
#
#   Repertoire racine HOME_DIR
#
#---------------------------------------------------
 
 
SOURCE_DIR 	= $(PWD)/
BASE_DIR 	= ..
HOME_DIR 	= ../..
 
#---------------------------------------------------
#
#  Liste des divers repertoires
#
#---------------------------------------------------
 
OBJECT_DIR 	= $(SOURCE_DIR)
EXE_DIR 	= $(HOME_DIR)/bin/$(MACHINE)
LIB_DIR         = $(HOME_DIR)/lib/$(MACHINE)
 
#---------------------------------------------------
#
#  Definir les divers .o (Objects)
#
#---------------------------------------------------
 
LIB_UTILS = $(LIB_DIR)/libmalib.a
 
OBJS = MonFile1.o \
	MonFile2.o
 
$(LIB_UTILS): $(OBJS)
	ar rv $(LIB_UTILS) $(OBJS) ;
	$(RANLIB) $(LIB_UTILS) ;
	cd $(SOURCE_DIR)
 
#######
#
#  dependances des Sources
#
#######
MonFile2.o: MonFile2.c $(INCLUDE_DIR)MesStructs.h 
 
#---------------------------------------------------
#
#  Directives pour la compilation
#
#---------------------------------------------------
 
.c.o:
	$(CC) $(CFLAGS)  $(INC_DIR) -c $< $(LDFLAGS) 
 
#---------------------------------------------------
#
# Cibles
#
#---------------------------------------------------
 
.IGNORE:
 
 
all:: $(LIB_UTILS)
 
 
clean::
	cd $(OBJECT_DIR); rm -f $(OBJS) ; cd $(SOURCE_DIR); rm -f *~ *.bkp
 
cleanlib::
	rm -f $(LIB_UTILS)

Si on modifie MesStructs.h, seulement MonFile2.c sera recompilé, même si MesStructs.h est inclus dans MonFile1.c ... par un simple make avec ce Makefile...

C'est pas ça que vous cherchez ??

[aoyou]

Pas vraiment, MonFile1.c doit être recompilé s'il utilise un élément qui a été modifié dans MesStructs.h.
Mais si aucun élément de MesStructs.h qu'il utilise n'a été modifié entre temps (et ce même si d'autres éléments de MesStructs.h ont été modifiés), MonFile1.c ne doit pas être recompilé.
Une solution basée sur make ne peut pas marcher. Il faut au moins partir d'un historique des fichiers tel que le fournit cvs ou svn.
Le but est de ne recompiler que ce qui est vraiment nécessaire pour ne livrer que le minimum.
C'est toutefois contraire à ce qui fait le plus couramment.