Outil Make simple

In article <op.u3u1ytmak9rspk@papillon>, TSalm <tsalm@free.fr> wrote:

Le Mon, 23 Nov 2009 16:30:40 +0100, Marc Espie <espie@lain.home> a écrit:

In article <pxbiqd1b8ec.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:

espie@lain.home (Marc Espie) writes:

Mais t'as toujours un petit probleme cote info-a-jour: faut faire
tourner
gcc -M pour fabriquer le fichier en question, ce qui se fait avec un
bout
de makefile. Mais une fois que ca a change, ben faut relancer make...
avec
les bonnes dependances.

Si je ne me trompe pas, les dependances sont invalidees exactement dans
les
memes circonstances que le fichier objet -- du moins tant qu'on s'en
tient
a la logique de make de se baser sur les dates.

C'est une des multiples limitations de make, gnu-make n'etant pas
mieux que
les autres (etant plutot pire cote documentation qui oublie de dire ce
qui
est specifique a gnu-make, et ce qui est standard).

Il y a quelques tentatives de ci, de la, pour faire mieux, mais rien de
vraiment concluant dans mon experience...

clearmake (mais avec tous les avantages et les inconveniants de
clearcase)
tant qu'on n'a pas de fichier qui peuvent etre mis a jour correctement
de
plusieurs manieres (la gestion historique des templates de Sun CC par
exemple posait probleme).

Revenons quand meme a la question de depart: le posteur initial voulait
un truc
simple, et qui marche... de quelque facon qu'on y regarde, make ne
remplit
pas ce cahier des charges. Deja, c'est pas tres simple, surtout pour du
C++,
mais surtout, si ca reste simple, ca ne marche pas (bien), et si ca ne
reste
pas simple, ca ne marche quand meme pas parfaitement...

Si tu entends par "ça ne marche pas bien", que ça oblige à avoir une façon
d'organiser ses sources qui soit restreinte, ça m'irait parfaitement bien.

Concernant mon organisation, c'est celle d'un débutant que je suis, et qui
me convient pas mal jusqu'ici :
- j'ai une racine, appelont la src/
- quand je fait un include avec des doubles-quotes (#include
"doss1/doss2/mon_fichier.hpp"), il est dans "src/doss1/doss2/"
- si le fichier .hpp dont mon executable dépends a un .cpp (même nom),
alors il faut générer ce .o et l'inclure lors du "linkage" de l'executable
- sur chaque executable à générer, on peut individuellement passer des
paramètres de compilation. Ceci pour indiquer où chercher les entêtes et
les librairies statiques.

Ca n'existe pas ce genre du truc? C'est plus compliqué que je le crois ?

C'est pas si simple que ca dans certains cas.

Vu ce que tu veux, tu devrais sans doute jeter un oeil a cmake. Ca fait un
gros bout de ce que tu veux, en cachant tous les details scabreux dans un
coin...

On Nov 23, 3:31 pm, es...@lain.home (Marc Espie) wrote:

In article <pxbtywlbgav....@news.bourguet.org>,
Jean-Marc Bourguet <j...@bourguet.org> wrote:
>Fabien LE LEZ <grams...@gramster.com> writes:

>> On Mon, 23 Nov 2009 01:14:06 -0800 (PST), James Kanze
>> <james.ka...@gmail.com>:

>> >C'est tout à fait possible de faire quelque chose du genre
>> >avec GNU make,

>> Comment fait-on, avec make, pour générer automatiquement
>> les dépendances ? Si je ne m'abuse, make tout seul ne sait
>> pas de quels .h un .cpp dépend.

>Tous les compilateurs que j'utilise ont des flags du genre
>-M? de GCC, qui permettent de recuperer l'info. Il suffit
>d'inclure le resultat dans le Makefile (ce qui suppose un
>make qui permet l'inclusion sans erreur si le fichier
>n'existe pas, comme GNU make).

Et même ceux qui ne l'ont pas, comme VC++, ont une option pour
obtenir la sortie du préprocesseur, avec ses #line, etc. Qu'on
passe à un script approprié, et le tour est joué.

Mais t'as toujours un petit probleme cote info-a-jour: faut
faire tourner gcc -M pour fabriquer le fichier en question, ce
qui se fait avec un bout de makefile. Mais une fois que ca a
change, ben faut relancer make... avec les bonnes dependances.

Il y a deux options : ou bien, tu as un cible spécial, depends,
qui génère les fichiers qui convienent quand on l'invoque, ou
bien, on le fait automatiquement chaque fois qu'on invoque make.
Le seul problème que j'ai jamais eu à cet égard, c'est quand
j'ai supprimé un en-tête. Et que make me disait qu'il ne
trouvait pas le fichier, et qu'il en avait besoin pour générer
ces fichiers de dépendance. Dans mon cas, un coup de make clean
suffisait, mais si on craint réelement les temps de compilation
qui s'en suivent, on pourrait bien concevoir un cible spécial
qui regénère les dependances, sans tenir compte de celles qui
existent. (L'inclusion du fichier avec les dépendences dépend,
évidemment, du cible ; on ne les inclut pas lors d'un make
clean, par exemple.)

C'est une des multiples limitations de make, gnu-make n'etant
pas mieux que les autres (etant plutot pire cote documentation
qui oublie de dire ce qui est specifique a gnu-make, et ce qui
est standard).

Quel standard ? Autant que je sache, il n'y a pas de norme de
make, et le sous-ensemble commun à tous les make est tellement
petit que d'être inutilisable. Dans l'ensemble, j'ai trouvé la
documentation de GNU make plutôt bon, au moins en ce qui
concerne les plateformes Unix. Les seules faiblesses que je lui
reconnaît, c'est l'organisation, que le rend parfois difficile à
trouver l'information voulue, et les explications de comment ça
fonctionne dans les environements autres qu'Unix. (Où, par
exemple, les chemins d'accès ont souvent des blancs, et prèsque
toujours un ':'. Et qu'il n'y a pas vraiment un shell standard
non plus. N'empêche qu'il fonctionne, que je m'en sers, et que
je suis même en train de l'écrire ce qu'il faut pour qu'il
utilise les dépendences et les règles de compilation du Visual
Studio.)

Il y a quelques tentatives de ci, de la, pour faire mieux,
mais rien de vraiment concluant dans mon experience...

Une partie du problème, je crois, c'est qu'ils veulent toujours
faire trop. Par exemple, je n'ai jamais trouvé un outil autre
que le compilateur qui arrive à déterminer correctement les
dépendences du point de vue du compilateur. (Jam, par exemple,
échoue complètement sur mes:
#include GB_dependentInclude(syst,Toto.hh)
qui include soit syst-posix/Toto.hh, soit syst-windows/Toto.hh,
selon le système sur lequel on se trouve.)

Que GNU make ait beaucoup de problèmes, j'en conviens, à
commencer par un grammaire basé sur le make initial. N'empêche
qu'il offre des possibilités de programmation de peu d'autres
outils, et que jusqu'ici, je n'ai pas vue d'autre alternatif qui
marche. (Sans oublier que pour moi, c'était mon introduction à
la programmation functionnelle.)

--
James Kanze

In article <5feeab02-8103-47e4-9a1f-095c0a4fdd62@x15g2000vbr.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:

Quel standard ? Autant que je sache, il n'y a pas de norme de
make, et le sous-ensemble commun à tous les make est tellement
petit que d'être inutilisable. Dans l'ensemble, j'ai trouvé la
documentation de GNU make plutôt bon, au moins en ce qui
concerne les plateformes Unix.

Tu sais mal. Il faudrait te mettre a jour. make fait partie de POSIX, tu peux
par exemple trouver sa documentation dans Single Unix d'opengroup.

Le sous-ensemble commun a tous les make *est* utilisable. Tu y trouves les
variables, y compris les variables magiques telles que $@, les dependances,
les suffix rules.

Meme des fonctionnalites sympathiques telles que
make VAR=value
(qui override la valeur specifiee dans le Makefile) sont normalises.


C'est parfaitement possible de faire des choses tres raisonnables avec
(d'ailleurs une proportion non negligeable de logiciels savent compiler
avec plusieurs make).

... mais le fait que tu ne saches pas qu'il y a une norme, et quelles sont
les extensions supportees par tel ou tel make montre qu'il y a un souci
dans la doc de gnu-make...

espie@lain.home (Marc Espie) writes:

Tu sais mal. Il faudrait te mettre a jour. make fait partie de POSIX, tu
peux par exemple trouver sa documentation dans Single Unix d'opengroup.

Le sous-ensemble commun a tous les make *est* utilisable.

Desole, de mon point de vue, l'absence d'include le rend inutilisable sans
generation (semi-)automatique des Makefiles eux-memes.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

"TSalm" <tsalm@free.fr> a écrit dans le message de groupe de discussion :
op.u3u1ytmak9rspk@papillon...

Le Mon, 23 Nov 2009 16:30:40 +0100, Marc Espie <espie@lain.home> a écrit:

Concernant mon organisation, c'est celle d'un débutant que je suis, et qui
me convient pas mal jusqu'ici :
- j'ai une racine, appelont la src/
- quand je fait un include avec des doubles-quotes (#include
"doss1/doss2/mon_fichier.hpp"), il est dans "src/doss1/doss2/"
- si le fichier .hpp dont mon executable dépends a un .cpp (même nom),
alors il faut générer ce .o et l'inclure lors du "linkage" de l'executable
- sur chaque executable à générer, on peut individuellement passer des
paramètres de compilation. Ceci pour indiquer où chercher les entêtes et
les librairies statiques.

Dans ce genre de cas, je refais une compilation complète de l'application.
Si l'utilisation de make te permet d'économiser du temps lors de la
compilation, alors son usage est indiqué, sinon, pour de simple utilitaire
cela ne se justifie pas. D'autant plus quand les règles de dépendance ne
sont pas clairement établies.

Merci à tous pour vos réponses.
Vu qu'il semble qu'il faut en passer par là, je vais déjà commencer par
apprendre les Makefile.

Le 23/11/2009 12:58, Fabien LE LEZ a écrit :
> On Mon, 23 Nov 2009 01:14:06 -0800 (PST), James Kanze
> <james.kanze@gmail.com>:
>
>> C'est tout à fait possible de faire quelque chose du genre avec GNU
>> make,
>
> Comment fait-on, avec make, pour générer automatiquement les
> dépendances ? Si je ne m'abuse, make tout seul ne sait pas de quels .h
> un .cpp dépend.

Non, en effet. Il faut utiliser l'option -MM du préprocesseur de gcc.
Mais
c'est facile d'inclure la commande dans le Makefile :

Par exemple :

#-----8<-----------------------------
depend:
gcc -MM *.cpp > dependencies.mk

# DEPENDANCES
-include dependencies.mk
#-----8<-----------------------------

et un "make depend" génère les dépendances.

Je refais automatiquement la dependance avec l'objet. Ca evite de devoir
se poser des questions quand a la necessite de faire un make depend.
Donc
pour gcc

CXXFLAGS=-MMD
-include $(OBJECTS:.o=.d)

pour les compilateurs sans equivalent de -MMD, c'est

-include $(OBJECTS:.o=.d)
.cpp.o:
$(CXX) -MM $(CFLAGS) $< > $(@:.o=.d)
$(CXX) -c $(CFLAGS) $(CXXFLAGS) -o $@ $<

(La seule chose a laquelle il faut faire attention, c'est introduire
explicitement les dependances sur les fichiers generes pour eviter que la
compil d'un fichier foire parce qu'un fichier genere n'est pas fait).

A+

--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/

On Nov 24, 10:05 am, es...@lain.home (Marc Espie) wrote:

In article
<5feeab02-8103-47e4-9a1f-095c0a4fd...@x15g2000vbr.googlegroups.com>,
James Kanze <james.ka...@gmail.com> wrote:

>Quel standard ? Autant que je sache, il n'y a pas de norme de
>make, et le sous-ensemble commun à tous les make est
>tellement petit que d'être inutilisable. Dans l'ensemble,
>j'ai trouvé la documentation de GNU make plutôt bon, au moins
>en ce qui concerne les plateformes Unix.

Tu sais mal. Il faudrait te mettre a jour. make fait partie de
POSIX, tu peux par exemple trouver sa documentation dans
Single Unix d'opengroup.

En effet. Je ne sais pas pourquoi je croyais que ce n'était pas
le cas. Je sais que dans la passée (assez distante, je l'avoue),
je me suis battu avec les variations dans les makes d'un Unix à
l'autre, et que je me suis resigné à l'utilisation de GNU make,
étant donné qu'il était disponible sur toutes les plateformes (y
compris MS-DOS), et qu'il était toujours compatible avec
lui-même (à peu près).

Le sous-ensemble commun a tous les make *est* utilisable. Tu y
trouves les variables, y compris les variables magiques telles
que $@, les dependances, les suffix rules.

Depuis le temps, j'utilise beaucoup plus de GNU make. Pour être
réelement utilisable, au minimum, il faut bien include, et
quelque chose pour faire des conditionnels. Dans mes fichiers
make d'aujourd'hui, je me sers de bien plus, au point qu'il me
faut même la version 3.81 de make, avec eval. (Du coup, je nomme
mes fichiers make GNUmakefile, de façon à ce que d'autres make
n'essaient même pas à les lire.)

Meme des fonctionnalites sympathiques telles que
make VAR=value
(qui override la valeur specifiee dans le Makefile) sont
normalises.

C'est parfaitement possible de faire des choses tres
raisonnables avec (d'ailleurs une proportion non negligeable
de logiciels savent compiler avec plusieurs make).

... mais le fait que tu ne saches pas qu'il y a une norme, et
quelles sont les extensions supportees par tel ou tel make
montre qu'il y a un souci dans la doc de gnu-make...

J'ajoute ça comme défaut dans la documentation, oui. Qu'il n'y a
pas de référence à la norme (sauf, je viens de voir, dans
l'introduction), et pas d'indication ce qui est extension, et ce
qui ne l'est pas. (Il y a bien des passages où la documentation
par « d'autres make ». Mais ils sont en général assez vagues, e t
ce n'est jamais clair quels autres make.)

De l'autre côté, on peut considérer GNU make quelque chose de
différent de Posix make : il peut exécuter les fichiers Posix
make, mais un peu comme F# peut exécuter du OCaml : sans
prétendre à être un Posix make pûr et dur. Alors, si tu veux
écrire GNU make, tu lis le manuel de GNU make, et si tu veux
écrire du Posix make, tu lis la norme Posix.

--
James Kanze

On Nov 24, 10:32 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:

es...@lain.home (Marc Espie) writes:
> Tu sais mal. Il faudrait te mettre a jour. make fait partie
> de POSIX, tu peux par exemple trouver sa documentation dans
> Single Unix d'opengroup.

> Le sous-ensemble commun a tous les make *est* utilisable.

Desole, de mon point de vue, l'absence d'include le rend
inutilisable sans generation (semi-)automatique des Makefiles
eux-memes.

Et l'absense des conditionnels rend son utilisation difficile
dans des environements multi-plateforme. (Bien que je suppose
qu'avec include, on pourrait implémenter certains conditionnels
en utilisant un macro dans le nom d'un fichier qu'on inclut.)

--
Jame Kanze

In article <576df9ab-6cb0-4cf2-821c-c738ba67cab4@f16g2000yqm.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:

J'ajoute ça comme défaut dans la documentation, oui. Qu'il n'y a
pas de référence à la norme (sauf, je viens de voir, dans
l'introduction), et pas d'indication ce qui est extension, et ce
qui ne l'est pas. (Il y a bien des passages où la documentation
par « d'autres make ». Mais ils sont en général assez vagues, et
ce n'est jamais clair quels autres make.)

De l'autre côté, on peut considérer GNU make quelque chose de
différent de Posix make : il peut exécuter les fichiers Posix
make, mais un peu comme F# peut exécuter du OCaml : sans
prétendre à être un Posix make pûr et dur. Alors, si tu veux
écrire GNU make, tu lis le manuel de GNU make, et si tu veux
écrire du Posix make, tu lis la norme Posix.

Mouais... ca tient seulement a moitie la route. Deja, il faut savoir
qu'il existe d'autres choses. Ensuite je corrige tres regulierement des
choses qui sont tres mineures dans des Makefile qui ne passeraient QUE
avec gnu-make, juste pour une merdouille inutile.

Ensuite, si tu te places dans une optique de "GNU uber alles" qui est
malheureusement un peu le cas du cote FSF hardcore (avec le classique:
si vous etes sur un autre Unix, commencez par installer les outils GNU,
vous serez tranquilles), ben c'est un peu la guerre pour continuer a
defendre des alternatives viables (surtout que l'epoque ou tu avais des
outils tres moyens sur d'autres Unix en dehors de GNU est quand meme tres
revolue...)

In article <cdbd9698-5081-4a0e-8422-718b4a844ef8@x31g2000yqx.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:

On Nov 24, 10:32 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:

es...@lain.home (Marc Espie) writes:
> Tu sais mal. Il faudrait te mettre a jour. make fait partie
> de POSIX, tu peux par exemple trouver sa documentation dans
> Single Unix d'opengroup.

> Le sous-ensemble commun a tous les make *est* utilisable.

Desole, de mon point de vue, l'absence d'include le rend
inutilisable sans generation (semi-)automatique des Makefiles
eux-memes.

Et l'absense des conditionnels rend son utilisation difficile
dans des environements multi-plateforme. (Bien que je suppose
qu'avec include, on pourrait implémenter certains conditionnels
en utilisant un macro dans le nom d'un fichier qu'on inclut.)

En pratique, la grande majorite des make supportent les include system V, a la
include "nom de fichier"
y compris avec des noms de variables dans le nom.

ce qui ne marche generalement pas, c'est les inclusions "au cas ou", ou il
existe plusieurs syntaxes differentes (-include, sinclude) qui dependent du
make considere.