Utiliser accolades dans une arborescence (dans un makefile)

Résolu/Fermé
Utilisateur anonyme - Modifié par orinym le 28/09/2013 à 05:50
mamiemando Messages postés 33077 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 18 avril 2024 - 30 sept. 2013 à 09:30
Bonjour,

Je suis en train de faire un makefile pour la construction de mon projet et j'ai mis mes .c dans un dossier src.

Ce makefile n'est pas fini mais voici son état actuel :

NAME_RELEASE=bsq
NAME_DEBUG=bsq_debug
INC=./includes/

TEST_SRC=./src/
MAIN_TEST=main_test.c
RELEASE_SRC=./src/
MAIN_RELEASE=main.c

DEBUG_DEP=./debug/
C_DEBUG=debug.c
H_DEGUG=debug.h

SRC_LONG=./src/
C_LONG=ft_long1.c ft_long2.c
LONG=$(C_LONG:" "=", ")
H_LONG=s_long.h



DEBUG=yes
CC=gcc
CFLAGS=-Wall -Werror -Wextra

ifeq ($(DEBUG), yes)
NAME=$(NAME_DEBUG)
else
NAME=$(NAME_RELEASE)
endif

all : $(NAME)

$(NAME_RELEASE) :

$(NAME_DEBUG) : debug.o s_long.o
$(CC) $(CFLAGS) -I $(INC) $(TEST_SRC)$(MAIN_TEST) -o $(NAME)

debug.o : $(INC)$(H_DEBUG) $(DEBUG_DEP)$(C_DEBUG)
$(CC) $(CFLAGS) -I $(INC) -c $(DEBUG_DEP)$(C_DEBUG) -o $@

s_long.o : $(INC)$(H_LONG) $(SRC_LONG){$(C_LONG)}
$(CC) $(CFLAGS) Ãf-I $(INC) -c $(SRC_LONG){$(C_LONG)} -o $@

Je vous explique à présent mon problème qui doit être en somme une notion bien basique.
Le problème se trouve dans la règle
s_long.o
, gcc va compiler une série de .c se trouvant dans ./src/
J'aimerais utiliser l'ensemble de ces .c à partir d'une variable contenant leurs noms avec un seul appel de gcc.
J'utilise pour cela diverses variables mais en gros, je cherche à utiliser la notation avec les accolades dans une arborescence (il me semble que cette manière de faire existe) :

./src/{file1.c, file2.c, file3.c, }

Seulement zsh me retourne l'erreur suivante :
zsh: parse error near '}'.

Il y a peut-être d'autres moyens de faire mais j'aimerais comprendre cette erreur-ci (je fais ce projet avant tout pour progresser), je n'ai rien trouvé sur google car je ne sais pas vraiment où chercher : ces notions doivent être trop détaillées.

J'aimerais également vérifier si la ligne suivante permet bien d'intercaller des virgule dans les espaces :
LONG=(C_LONG:" "=", ")

Car je sais que
OBJ= $(SRC:.c=.o)
permet d'assigner la valeur de SRC à OBJ en remplaçant toutes les occurences de .c par .o . (les guillements me permettront j'espère de prendre en compte les espaces mais je ne suis pas sûr de cette notation).

EDIT: je me suis appuyé sur ce cours pour élaborer ce makefile :
https://gl.developpez.com/tutoriel/outil/makefile/

EDIT bis :
Le
LONG=(C_LONG:" "=", ")
ne fonctionne malheureusement pas.

Merci d'avance pour vos lumières!
A voir également:

2 réponses

mamiemando Messages postés 33077 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 18 avril 2024 7 748
28 sept. 2013 à 11:26
Ça me paraît suspect d'avoir plusieurs ".c" utilisé pour former un simple ".o", et j'avoue ne pas vraiment voir l'intérêt (d'ailleurs il faudrait vérifier que la commande gcc que tu veux déclencher fonctionne dans un shell avant de la traduire en makefile).

Généralement la réunion de plusieurs ".o" se traduit par une librairie statique (".a") ou dynamique (".so"), et ensuite tu peux lier ton projet à cette librairie.

Ici tu as un makefile générique "maison" :
https://forums.commentcamarche.net/forum/affich-21500291-pb-makefile-suite-portage-vers-autre-noyau#7

Sinon l'idéal, c'est d'utiliser des outils comme automake et compagnie, mais disons que ce n'est pas trivial à utiliser.

Bonne chance
0
Utilisateur anonyme
28 sept. 2013 à 12:04
Bonjour, tout d'abord merci pour votre réponse.

Je me posais justement la question pour ce problème de .o/.c.
L'intérêt est que pour nos études nous sommes soumis à une norme pour coder qui limite le nombre de fonctions par fichier, nous sommes donc obligés de faire plusieurs fichiers pour respecter ladite norme.
Ce n'est pas négociable.

Ceci dit l'idée des .a est sans doute la meilleure pour faire des bibliothèques j'aurais du y penser c'est vrai.
Je ne pense pas qu'il soit possible avec gcc de faire un unique .o avec plusieurs .c. l'option -c n'admet pas de nom de cible et est incompatible avec -o.

Ceci dit, j'ai toujours le problème de savoir utiliser les {} dans une arborescence, j'avais vu cette notation mais je ne parviens pas à la reproduire ou à en trouver une explication sur internet.
elle permet en principe d'utiliser plusieurs fichiers d'un dossier autre que le dossier courant sans avoir à retaper l'arborescence pour chaque fichier.
0
mamiemando Messages postés 33077 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 18 avril 2024 7 748
28 sept. 2013 à 12:27
Je me posais justement la question pour ce problème de .o/.c.
L'intérêt est que pour nos études nous sommes soumis à une norme pour coder qui limite le nombre de fonctions par fichier, nous sommes donc obligés de faire plusieurs fichiers pour respecter ladite norme.


Tu diras de ma part à ton prof que sa convention est stupide, car c'est le meilleur moyen d'inciter les élèves à faire des grosses fonctions bien moches au lieu d'écrire un programme bien structuré.

Ceci dit, il faudrait voir le fichier dont tu parles, peut-être que les fonctions qu'il expose pourraient être séparées en plusieurs fichiers (et chacun d'eux conduirait à générer un ".o").

Par exemple supposons que ce fichier s'appelle "maths.h" et qu'il regroupe des fonctions de trignométrie et d'algebre, on pourrait imaginer avoir un dossiers maths qui contient un fichier trignometrie.h et algebre.h. Et dans ce cas là, effectivement, c'est un découpage qui réduit le nombre de fonctions et qui a du sens. Et c'est à mon avis la "bonne" manière de résoudre le problème.

Maintenant, si on revient à ton fichier découpé en 3 sous fichiers, je ne vois pas l'intérêt de compiler les 3 dans le même ".o".

Ceci dit l'idée des .a est sans doute la meilleure pour faire des bibliothèques j'aurais du y penser c'est vrai.

À mon avis c'est disproportionné vu ton besoin.

Je ne pense pas qu'il soit possible avec gcc de faire un unique .o avec plusieurs .c. l'option -c n'admet pas de nom de cible et est incompatible avec -o.

Je ne pense pas non plus car je n'en ai jamais eu le besoin. À mon avis ce n'est pas possible car ça n'a aucun intérêt :-)

Ceci dit, j'ai toujours le problème de savoir utiliser les {} dans une arborescence, j'avais vu cette notation mais je ne parviens pas à la reproduire ou à en trouver une explication sur internet.

C'est peut être une notation qui dépend du shell. Par exemple en bash tu peux écrire
ls /{home,etc}
qui liste le contenu de /home /etc. Ceci dit si ton makefile dépend du shell utilisé, ce n'est pas bon signe, car ça veut dire que quelqu'un qui n'utilise pas le bon shell ne pourra pas compiler ton programme.

Bonne chance
0
Utilisateur anonyme
28 sept. 2013 à 12:38
Tu diras de ma part à ton prof que sa convention est stupide, car c'est le meilleur moyen d'inciter les élèves à faire des grosses fonctions bien moches au lieu d'écrire un programme bien structuré.

Nous sommes également limités en nombre de lignes et de colonnes par fonctions.


C'est peut être une notation qui dépend du shell. Par exemple en bash tu peux écrire
ls /{home,etc}
qui liste le contenu de /home /etc. Ceci dit si ton makefile dépend du shell utilisé, ce n'est pas bon signe, car ça veut dire que quelqu'un qui n'utilise pas le bon shell ne pourra pas compiler ton programme.


C'est peut-être parce-que je suis en zsh? :/

Merci pour votre réponse.
0
mamiemando Messages postés 33077 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 18 avril 2024 7 748
28 sept. 2013 à 12:44
Nous sommes également limités en nombre de lignes et de colonnes par fonctions.

Ça, à la limite ça me choque moins. Si tu utilises un outil de développement pour coder (par exemple kdevelop, anjuta, ou même un bon vieux vim) tu peux configurer ton éditeur pour qu'il passe automatiquement à la ligne quand tu atteins cette limite.

C'est peut-être parce-que je suis en zsh

Peu importe ce n'est pas la bonne manière de faire. Découpe simplement ton gros fichier ".c" en plusieurs fichiers ".c" (en faisant un découpage logique) et compile un fichier ".o" par fichier ".c" et à mon avis tu résoudras tous tes problèmes.
0

Ça, à la limite ça me choque moins. Si tu utilises un outil de développement pour coder (par exemple kdevelop, anjuta, ou même un bon vieux vim) tu peux configurer ton éditeur pour qu'il passe automatiquement à la ligne quand tu atteins cette limite.


Je fais tout sous tty avec emacs.


Peu importe ce n'est pas la bonne manière de faire. Découpe simplement ton gros fichier ".c" en plusieurs fichiers ".c" (en faisant un découpage logique) et compile un fichier ".o" par fichier ".c" et à mon avis tu résoudras tous tes problèmes
.
Je me retrouve cependant avec le problème de la lecture: c'est assez lourd.
Mais bon j'en serai sûrement réduit à ça.
Si cette notation fonctionne sous bash, elle ne semble pas fonctionner sous zsh malheureusement. Pour l'activer, je pense que je devrais passer en bash au début du makefile.
EDIT: si, en fait cela fonctionne, c'étaient les espaces que j'avais rajoutés qui pourrissaient la commande.
Merci :)
0
mamiemando Messages postés 33077 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 18 avril 2024 7 748
29 sept. 2013 à 11:44
Je fais tout sous tty avec emacs.

https://stackoverflow.com/questions/8772488/emacs-word-wrap-at-specific-column-number

Je me retrouve cependant avec le problème de la lecture: c'est assez lourd.
Mais bon j'en serai sûrement réduit à ça.


Pas compris. En général découper en plein de petits fichiers (si ce découpage est logique) tend plutôt à améliorer la lisibilité.

EDIT: si, en fait cela fonctionne, c'étaient les espaces que j'avais rajoutés qui pourrissaient la commande.

Ok :)

Donc ton problème est résolu ?
0
Utilisateur anonyme
29 sept. 2013 à 16:08
mon problème est résolu, j'avais simplement oublié de le marqué comme tel, je corrige ce détail de suite.

Encore merci!
0