Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Outil Make simple

Outil Make simple

50 réponses
Avatar
TSalm
Bonjour,

Je cherche un outil qui me permette de lancer des compilations de façon
simple sur un projet de plusieurs executables.

Quand je dis simple, je veux dire qui sache trouver automatiquement les
dépendances, qui génére les fichiers .o seulement s'ils ne sont pas à jour
avec leurs sources, et qui m'oblige à une certaine organisation de mes
sources évidemment.

Qui fait que je n'ai plus qu'à lancer une compilation de mon executable,
plein d'autres dépendances, de cette façon :
$MON_OUTIL chemin/vers/mon/exe.cpp

Ca existe ?

Merci d'avance pour vos conseils.
-TSalm
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Gabriel Dos Reis
Michael Doubez writes:

[...]

| Je pense que c'est comme en C quand tu utilises des macros en
| metalangage pour construire ton programme: tant que tu ne sors pas des
| chemins battus, ça se passe bien.

en général, on ne sort pas des chemins battus quand il s'agit de logiciel
non-expérimental :-)

| Ce qui veut dire que ça se passe bien en général :)

-- Gaby
Avatar
Gabriel Dos Reis
(Marc Espie) writes:

[...]

| > Je voulais parler des autotools pour savoir ce que vous en pensiez
| >tous, et surtout si vous l'utilisiez. Mais vu ta réaction, j'ai peu r que
| >ça ne tourne au Troll bien velu :'(
|
| Je pense enormement de mal des autotools. Typiquement, ces derniers temps
| ils permettent surtout de verifier que ca compile sur plusieurs variations
| de linux/i386... j'ai passe suffisamment de temps a corriger des tonnes de
| bugs sur ceux-ci pour ne plus du tout les aimer (entre autres, des cons
| qui utilisent sed -i dans un configure.ac...)

Je suis persuadé qu'ils apprécieront des patches pour les autres systèmes.

-- Gaby
Avatar
Gabriel Dos Reis
James Kanze writes:

| On Nov 26, 2:49 pm, Michael Doubez wrote:
| > On 26 nov, 14:03, (Marc Espie) wrote:
|
| > > In article oups.com>,
|
| [...]
| > > Parce que mv file file.old && sed <file.old >file c'est pas
| > > sorcier.
|
| > Et pourtant il y a une erreur pour avoir le même comportement
| > ;) mv file file.old && sed <file.old >file && rm file.old
|
| J'espère que ce n'est pas le comportement du -i. Sinon, c'est à
| éviter. Comme j'ai dire ailleurs, il ne faut pas détruire
| l'original si on rencontre une erreur lors de la transformation.

Dans ce cas, la commande 'rm file.old' n'est jamais exécutée. Non?
Avatar
Gabriel Dos Reis
(Marc Espie) writes:

| In article .com>,
| Michael Doubez wrote:
| >Dans le cas d'un printf()/str*(), la question est "Est ce que ça po rte
| >à conséquence que la chaine soit NULL ?"
| >Pas vraiment si on considère seulement la chaine de caractères et les
| >services rendus par ces fonctions (affichage, calcul, comparaison).
| >L'erreur existerait aussi si le programmeur s'était trompé de chaine à
| >comparer.
| >Dans ce cas, AMA la robustesse peut être un choix valide: si le cod eur
| >doit avoir une chaine non NULL autre part, ce n'est pas en relation
| >avec les fonction strxxx(), et c'est donc de sa responsabilité de
| >vérifier ses contrats.
|
| Non, en pratique ca fout une merde pas possible. Le bon comportement, ca
| serait d'etre robuste *et* de diagnostiquer le probleme (en affichant
| par exemple quelque chose sur stderr).
|
| Dans ce cas extremement precis, ca fait des programmes qui segfaultent
| des qu'on les compile et execute sur un Unix, et qui tournent sans bronch er
| cote Linux.

Cela m'a l'air bien *nix-centrique, pour quelqu'un qui se plaint de la
dominance GNU/Linux.

-- Gaby
Avatar
espie
In article ,
Gabriel Dos Reis wrote:
(Marc Espie) writes:

[...]

| > Je voulais parler des autotools pour savoir ce que vous en pensiez
| >tous, et surtout si vous l'utilisiez. Mais vu ta réaction, j'ai peur que
| >ça ne tourne au Troll bien velu :'(
|
| Je pense enormement de mal des autotools. Typiquement, ces derniers temps
| ils permettent surtout de verifier que ca compile sur plusieurs variations
| de linux/i386... j'ai passe suffisamment de temps a corriger des tonnes de
| bugs sur ceux-ci pour ne plus du tout les aimer (entre autres, des cons
| qui utilisent sed -i dans un configure.ac...)

Je suis persuadé qu'ils apprécieront des patches pour les autres systèmes.



C'est tout le framework qui est a jeter, a ce niveau... deja, distribue
du shell script auto-genere, beurk.

Tu veux un exemple ? il y a eu un probleme de securite dans libtool,
conduisant a une version *b d'une version existante.

Le gugusse qui a fait la release a eu l'idee geniale de tout verifier
sur son systeme, avec un nouvel automake. Resultat: 8000 lignes de diffs,
dans lesquelles chercher LE probleme de securite de deux lignes (pour
backporter sur une ancienne version)... pas tres surprenant qu'il y ait
deja eu plusieurs personnes qui foutent des troyens dans du auto*shit.
Pas grand monde n'a la patience pour s'assurer que les 8000 lignes de diffs
sont bien "du bruit" et pas des problemes.

Au passage, le code correspondant de libltdl est lui-meme a gerber. Je ne
serais pas surpris qu'il y ait d'autres failles dedans, vu l'immonde plat
de spaghettis et de tests divers et varies.

A mon avis, ca n'est pas du tout un hasard si kde, par exemple, s'est
finalement affranchi d'automake/autoconf/libtool. Entre autres, la structure
en Makefile recursifs augmentait terriblement les temps de compilation sur
toutes les plateformes disposant de plusieurs processeurs (make -j n'est
efficace QUE si on peut compiler plusieurs trucs dans le meme Makefile).

Mais bon, on est plus dans l'idee de faire une version qui marche de libtool
par exemple, meme si elle sera au depart reduite a OpenBSD, et ne suivant
pas les dogmes en vigueur (e.g., c'est du perl recent, et ca permet d'ores
et deja de compiler pas mal de trucs bien plus vite que le libtool gnu).
Et en plus, ca marche chez nous, sachant que reparer un shell-script de
8000 lignes qui prend l'eau de toutes parts, qui ne peut pas pas marcher
correctement pour autre chose que des lib elf linux, et qui n'a pas
reellement de notion de packager (on installe a l'endroit definitif...),
c'est du SM extreme...
Avatar
TSalm
Le Fri, 27 Nov 2009 17:40:26 +0100, ld a écrit:

On 24 nov, 22:21, TSalm wrote:
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.



Puisque c'est cette direction que vous avez choisi, jetez un oeil sur
la GNU Make Standard Library

http://gmsl.sourceforge.net/

Ca n'explique pas les fondements de make, mais plutot comment faire
des macros utiles.

a+, ld.



Bon, ce n'est pas encore très utile à mon (petit) niveau, mais je garde ça
de côté.
Merci
Avatar
Gabriel Dos Reis
(Marc Espie) writes:

| In article ,
| Gabriel Dos Reis wrote:
| > (Marc Espie) writes:
| >
| >[...]
| >
| >| > Je voulais parler des autotools pour savoir ce que vous en pensiez
| >| >tous, et surtout si vous l'utilisiez. Mais vu ta réaction, j'ai peur que
| >| >ça ne tourne au Troll bien velu :'(
| >|
| >| Je pense enormement de mal des autotools. Typiquement, ces derniers te mps
| >| ils permettent surtout de verifier que ca compile sur plusieurs variat ions
| >| de linux/i386... j'ai passe suffisamment de temps a corriger des tonne s de
| >| bugs sur ceux-ci pour ne plus du tout les aimer (entre autres, des cons
| >| qui utilisent sed -i dans un configure.ac...)
| >
| >Je suis persuadé qu'ils apprécieront des patches p our les autres systèmes.
|
| C'est tout le framework qui est a jeter, a ce niveau... deja, distribue
| du shell script auto-genere, beurk.

Donc, ton probleme c'est pas qu'ils verifient que leur "truc" marche sur
des variations de linux/i386...

-- Gaby
Avatar
espie
In article ,
Gabriel Dos Reis wrote:
(Marc Espie) writes:



| In article ,
| Gabriel Dos Reis wrote:
| > (Marc Espie) writes:
| >
| >[...]
| >
| >| > Je voulais parler des autotools pour savoir ce que vous en pensiez
| >| >tous, et surtout si vous l'utilisiez. Mais vu ta réaction, j'ai
peur que
| >| >ça ne tourne au Troll bien velu :'(



| >| Je pense enormement de mal des autotools. Typiquement, ces derniers temps
| >| ils permettent surtout de verifier que ca compile sur plusieurs variations
| >| de linux/i386... j'ai passe suffisamment de temps a corriger des tonnes de
| >| bugs sur ceux-ci pour ne plus du tout les aimer (entre autres, des cons
| >| qui utilisent sed -i dans un configure.ac...)



| >Je suis persuadé qu'ils apprécieront des patches pour les
autres systèmes.



| C'est tout le framework qui est a jeter, a ce niveau... deja, distribue
| du shell script auto-genere, beurk.



Donc, ton probleme c'est pas qu'ils verifient que leur "truc" marche sur
des variations de linux/i386...



Ben, quand les problemes necessitent de tout refaire (ou presque) pour que
ca fonctionne ailleurs que sur des variations de linux/i386, c'est qu'il y
a un vrai souci.
Avatar
James Kanze
On Nov 27, 6:00 pm, Gabriel Dos Reis wrote:
James Kanze writes:



> On Nov 26, 8:49 am, Michael Doubez wrote:
> > On 25 nov, 18:16, James Kanze wrote:
> > [snip]
> > Il y a aussi les outils gnuwin32 (dont make) qui permettent
> > d'avoir les outils classics en win32 natif. Je les utilise
> > pour compléter mon install de MinGW avec sed, cat, wget ... et
> > même les expression [ - f ... ]. Le seul conflit que j'ai
> > trouvé avec Windows est avec echo et find.



> En effet.



> En général, les ports plus ou moins complets des outils Unix
> (CygWin, MinGW) s'integrent mal dans Windows, et posent des



Je n'ai pas de problème particulier avec MSYS/MinGW -- c'est
une plateforme de cross-compilation qui remplit largement son
but. Il n'a aucune prétention de fournir POSIX.



Ce n'est pas Posix que je démande ; je suis sous Windows, et non
sur une plateforme Unix. Et le problème et avec CygWin et avec
MinGW, c'est qu'ils essaient à cacher le fait. Les deux créent
leur propre image du système de fichiers, par exemple, avec
'/cygdrive/c/' sous CygWin et '/c/' sous MinGW. Ce qui veut dire
que sous CygWin, si tu entres le nom de fichier d'une façon que
l'achèvement des noms de fichiers marche, les autres programmes
ne le comprenent. MinGW, en revanche, le remappe (au moins dans
certains cas). Jusqu'à remplacer un '/' initial avec
"c:/msys/...", ce qui pose un problème pour les programmes
Windows, qui utilise '/' comme on utilise '-' sous Unix.

Si je voulais Unix (et quelque chose qui s'approche de Posix),
j'installerais Linux. Si je suis sous Windows, c'est que je veux
un certain nombre des fonctionalités de Windows. Si j'installe
CygWin ou MSys en plus, ce n'est pas que je veux un environement
Unix complet ; c'est que je veux quelques uns des fonctionalités
d'Unix dont je n'ai pas trouvé d'équivalent sous Windows -- des
choses comme awk, par exemple, où la version Unix de find (« find
| xargs egrep », c'est essentiel quand il faut se retrouver dans
une masse énorme de code existant, sans documentation). Voire
même la possibilité d'éditer la ligne de commande sans éloigner
mes doigts de la position de base. (Le shell Windows que je
connais ne permet l'édition qu'au moyen des touches de fleches.)

--
James Kanze
Avatar
James Kanze
On Nov 27, 6:09 pm, Gabriel Dos Reis wrote:
James Kanze writes:



> On Nov 26, 2:49 pm, Michael Doubez wrote:
> > On 26 nov, 14:03, (Marc Espie) wrote:



> > > In article groups.com>,



> [...]
> > > Parce que mv file file.old && sed <file.old >file c'est pas
> > > sorcier.



> > Et pourtant il y a une erreur pour avoir le même comportement
> > ;) mv file file.old && sed <file.old >file && rm file.old



> J'espère que ce n'est pas le comportement du -i. Sinon,
> c'est à éviter. Comme j'ai dire ailleurs, il ne faut pas
> détruire l'original si on rencontre une erreur lors de la
> transformation.



Dans ce cas, la commande 'rm file.old' n'est jamais exécutée.
Non?



Non, mais le ficher « file » a quand même disparu. Je préfère de
loin la version :

sed file > unTemporaire && mv unTemporaire file

Mais évidemment, pour avoir la fonctionnalité de -i, il faudrait
plutôt :
for x
do sed $x > unTemporaire && mv unTemporaire $x
done
Et encore, le comportement n'est pas tout à fait identique en
cas d'erreur.

--
James Kanze
1 2 3 4 5