1

yop,

Soit cette solution proposée pour générer automagiquement les dépendances avec un makefile + gcc : http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/#tldr
Est-ce que c'est ce que vous faites, ou réinventez-vous un truc custom pour chaque projet ? Et si oui, en fonction de quoi ? Quels problèmes rencontreriez-vous avec cette solution ?

Merci bien. smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

2

hum

perso j'ai laissé tomber ce genre de choses ca marche jamais embarrassed

Voila un Makefile classique fait a la main et amour :

CXX = clang++
CC = clang

#For Debug
#CFLAGS = -g -fomit-frame-pointer -funroll-loops -Iinclude -DDEBUG

#For Retail
CFLAGS = -O3 -fomit-frame-pointer -funroll-loops -Iinclude
LDFLAGS = -lpthread -lglfw3 -framework Cocoa -framework OpenGL -framework IOKit -framework CoreVideo
OBJS=video.o peripherals.o corecpu.o memory.o loadfile.o graphic.o main.o
all: u6502

u6502: $(OBJS)
	@echo " LD  $@"
	@$(CC)  -o $@ $(LDFLAGS) $?

.c.o:
	@echo " CC  $@"
	@$(CC) $(CFLAGS) -c $? -o $@

clean:
	@echo " Cleaning..."
	@rm -Rf $(OBJS) *~

Ca prends 5min a ecrire, ca march tres bien, pour un nouveau projet ya 3 lignes a changer (LDFLAGS/OBJS et la cible au nom du projet)


(et pour ceux qui veulent savoir, u6502 est une implementation native de ca: http://www.6502asm.com enfin pas l'assembleur, juste l'environnement d'execution grin)
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

3

Je n'utilise plus make pur et dur, j'utilise CMake pour les projets PC (et KTIGCC pour les projets TI-68k smile).
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

4

Euh...
Merci Godzil, mais où est-il question de dépendances dans ton Makefile ? cheeky
Kevin -> et les dépendances avec CMake alors, ça se passe comment ?
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

5

Sous FreeBSD on a mkdep pour ca :

Makefile:CC?= cc SRCS= main.c test.c OBJS= $(SRCS:.c=.o) NAME= test CFLAGS= -Wall ${NAME}: ${OBJS} ${CC} ${OBJS} -o ${NAME} clean: rm -f ${OBJS} ${NAME} depend: mkdep ${SRCS}
main.c:#include "test.h" int main(int argc, char *argv[]) { test(); return (0); }
test.c:#include <stdio.h> void test(void) { printf("Test\n"); }
test.hvoid test(void);
Quand je "make depend" ca cree un .depend avec les dependance que make(1) interprete automatiquement

.depend:# main.c test.c main.o: main.c test.h test.o: test.c /usr/include/stdio.h /usr/include/sys/cdefs.h \ /usr/include/sys/_null.h /usr/include/sys/_types.h \ /usr/include/machine/_types.h /usr/include/x86/_types.h \ /usr/include/machine/_limits.h /usr/include/x86/_limits.h

6

Folco: je l'ai fait un temps, j'ai passe et perdu plus de temps a essayer de comprendre comment était foutu ces machin a base de magie noir makefilienne que de service rendu. Au final, j'ai laisse tomber car ca ne sert quasiment a rien, au pire si un header est généré, il suffit de mettre une règle explicite.

Les headers systèmes ne changent pas, ou en tout cas si ils changent de manière notable tu auras d'autre problèmes, si ton code change les headers de manière notable un make clean / make est la plus simple et sure des solutions.

J'ai eu des cas bizarre ou les dépendances n’était pas correctement calcule et ça faisait des choses anormales.

Bref, j’évite soigneusement :/

EDIT: Pour simplifier, tout ce qui invoque de la magie noir dans un makefile j’évite soigneusement, la maintenabilite avant tout.
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7

Godzil (./6) :
Les headers systèmes je changent pas, ou en tout cas si ils changent de manière notable tu auras d'autre problèmes, si ton code change les headers de manière notable un make clean / make est la plus simple et sure des solutions.

Oui mais généralement tu oublie que tu as modifié des trucs dans tes headers et tu comprend pas pourquoi ça foire.
Avoir les dépendance gérer par ton système de compilation (peut importe lequel) te simplifie le problème grandement.
Et bien sur dans le cas d'un gros projet long a compiler tu recompile que ce que tu as besoin.

8

Moins toutes les fois ou ca foire.

Il est preferable, si plein de gros changement, de faire un rebuild-all

Le nombre d'emmerdes que j'ai évite a maintenir et faire confiance a un machin de dépendances m'a fait plus gagner de temps que l'inverse.

Et si le projet commence a être relativement gros, make c'est de toute manière pas une solution viable a long terme, c'est très bien pour des petits projets a moyen projets. les trucs vraiment gros et lourd, multidependants & co on va passer sur du cmake ou équivalent parce que ça simplifie la maintenant de la chaîne de build. J'y suis passe par la, ma première boite on utilisait make de manière historique, une de mes taches de fond était de trouver un moyen de s'en débarrasser parce que toute la magie noir mise dedans pour que ça marche posais plus de problème qu'autre chose au long terme.
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

9

On s'en sort très bien avec seulement make dans le monde BSD et je crois que le kernel Linux c'est pareil.
Attention je dis pas que c'est simple, mais c'est clairement faisable pour un petit/moyen projet.

Après si y'a plein de dépendance externe, oui un truc du genre CMake/Autotool est clairement mieux.

10

Folco (./4) :
Kevin -> et les dépendances avec CMake alors, ça se passe comment ?
Pour du code C ou C++, CMake les détecte automatiquement.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

11

Il y a enormement de magie noir dans les makefiles du kernel. Pas ceux qu'on vois a cote des sources, mais ceux cache dans /script/
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

12

Godzil -> merci bien, mais je demandais comment gérer les dépendances, pas tout le mal que tu en penses...

El Barto -> Merci bien ! smile

Kevin -> Super merci ! Je vais probablement utiliser CMake. Le seul problème que j'ai rencontré avec, et qui limite la portabilité dans la pratique, c'est que tous les programmes ne sont pas livrés avec un module CMake, et donc dès qu'on change d'OS il faut adapter, ce qui est le contraire du but initial (la portabilité).
Cependant, je vais voir si on peut détecter proprement Linux et Windows dans CMake, sans hack crade.
smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

13

Il n'y a pas de "hack crade" a faire pour cmake pour savoir sous quel OS tu es, il y a des defines automatique pour ca:

[code]IF (WIN32)
# set stuff for windows
ELSE()
# set stuff for other systems
ENDIF()[/code]

Il y a pour OS X aussi et probablement un LINUX si besoin.

cf: https://cmake.org/Wiki/CMake_Useful_Variables
UNIX 
    is TRUE on all UNIX-like OS's, including Apple OS X and CygWin 
WIN32 
    is TRUE on Windows. Prior to 2.8.4 this included CygWin 
APPLE 
    is TRUE on Apple systems. Note this does not imply the system is Mac OS X, only that __APPLE__ is #defined in C/C++ header files. Obtain more specific system information via CMAKE_SYSTEM_VERSION, i.e. IF(${CMAKE_SYSTEM_NAME} MATCHES "Darwin"), then it's Mac OS X. 
MINGW 
    is TRUE when using the MinGW compiler in Windows 
MSYS 
    is TRUE when using the MSYS developer environment in Windows 
CYGWIN 
    is TRUE on Windows when using the CygWin version of cmake 
BORLAND 
    is TRUE on Windows when using a Borland compiler 
WATCOM 
    is TRUE on Windows when using the Open Watcom compiler 
MSVC, MSVC_IDE, MSVC60, MSVC70, MSVC71, MSVC80, CMAKE_COMPILER_2005, MSVC90, MSVC10 (Visual Studio 2010) 
    Microsoft compiler

Et mon propos était plutôt, "as tu vraiment besoin de faire ce genre de choses"?
Combien de headers ton projet compte, combien sont change très régulièrement au points de pouvoir casser une build sans tout recompiler, combien de temps ton projet met a compiler depuis 0, et est-ce que l'effort de comprendre comment ça marche avec make va vraiment apporter quelque chose?

N'oublie pas, tout bon développeur est a la base fainéant, mais n'aime pas non plus les choses mal faites: fainéant en veux pas dire faire les choses de manière crade, mais veux dire ne pas se faire chier a faire un truc qui au final ne servira a rien.

Utiliser cmake est probablement une bonne solution si tu veux absolument avoir quelque chose de propre qui gère les descendances, bien plus propre que tout la magie noir makefile-ienne. Si tu te retrouve a faire des makefile avec des cibles "virtuelle" des PHONY a droite a gauche et plein de choses cryptiques a base de %, rewrite de variable etc.. c'est qu'il faut aller chercher un autre outil que make. CMake est je pense une bonne solution dans la majorité des cas.
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

14

C'est bien vers ça que je vais me tourner, les dépendances et la détection de l'OS étaient les deux trucs qui me faisaient suer avec Make. Merci bien pour ton lien. smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

15

Oui ca fait partit des choses assez.. horrible a faire en pur Makefile :/
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

16

Sinon, la manière propre de gérer les dépendances inconnues à CMake, c'est de livrer ton propre Find*.cmake avec ton projet. Tu peux souvent trouver un Find*.cmake existant quelque part. Il y a aussi les extra-cmake-modules (ECM) de KDE qui pourraient déjà avoir ce que tu cherches.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

17

J'ai des Find*.cmake pour SDL, trouvés sur le net (github). C'est quand même con que ce soit pas fourni par les projets. Mais SDL, c'est comme leur doc, ils sont très minimalistes pour ce genre de trucs.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !