- La syntaxe sujette aux erreurs ;
- Les appels récursifs à make posent problème ;
- Le manque de modularité ;
- L'absence d'atomicité de l'application des règles.
Daniel J. Bernstein, l'auteur de qmail et djbdns, a proposé une alternative à Make qu'il a appelée redo, mais celle-ci se présente sous forme de notes et non pas de code.
Avery Pennarun a trouvé ses notes et en a écrit une version en Python sous licence LGPL.
Redo fonctionne avec des scripts shell avec l'extension .do et chacun de ces fichiers décrit une règle. Par exemple, le fichier default.o.do qui servirait à générer des fichiers .o à partir des sources .c correspondantes s'écrirait de cette façon :
redo-ifchange $1.c
gcc -MD -MF $3.deps.tmp -c -o $3 $1.c
DEPS=$(sed -e "s/^$3://" -e 's/\\//g' <$3.deps.tmp)
rm -f $3.deps.tmp
redo-ifchange $DEPSAller plus loin
- Redo sur github (38 clics)
- L'annonce de redo (8 clics)
- Les notes de D. J. Bernstein (7 clics)
- Une introduction rapide à Redo (25 clics)
- Redo from scratch (14 clics)
- La mailing-list de redo (5 clics)
# Ant ?
Posté par syj . Évalué à 1.
Personnellement ,si il y a un programme qui pourrait remplacer Make , c'est Ant à mon avis.
Déjà par l'antériorité mais aussi par la souplesse de cette outil qui est presque sans limite.
La bibliotheque de "task" est déjà énorme et te permet de scripter n'importe quoi et surtout réellement multi-plateforme.
Enfin ,tu peux créer très simplement des "Task" maison et les intégrés des scripts Ant.
http://ant.apache.org/manual/tasksoverview.html
[^] # Re: Ant ?
Posté par claudex . Évalué à 10.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ant ?
Posté par 2PetitsVerres . Évalué à 10.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Ant ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 10.
Le XML, c'est comme la violence : si ça marche pas, c'est qu'il n'y en a pas assez.
[^] # Comparaison du chargement d'une VM python et chargement d'une VM Java
Posté par syj . Évalué à 2.
class Main {
public static void main(String[] args) {
System.out.println("Hello the world");
}
}
syj@syj-laptop:~/todelete$ cat hello.py
print "Hello the world
syj@jsyj-laptop:~/todelete$ time java Main
Hello the world
real 0m0.070s
user 0m0.028s
sys 0m0.036s
syj@syj-laptop:~/todelete$ time python hello.py
Hello the world
real 0m0.023s
user 0m0.016s
sys 0m0.008s
[^] # Re: Comparaison du chargement d'une VM python et chargement d'une VM Jav
Posté par Gniarf . Évalué à 4.
[^] # Re: Comparaison du chargement d'une VM python et chargement d'une VM Jav
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
dd traite plusieurs projets en //
[^] # Re: Comparaison du chargement d'une VM python et chargement d'une VM Jav
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comparaison du chargement d'une VM python et chargement d'une VM Jav
Posté par zebra3 . Évalué à 9.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ant ?
Posté par Enjolras . Évalué à 4.
Ant je veux bien, mais utiliser java pour la compilation, ça a de sérieux inconvénients en contre partie de sa portabilité pour une utilisation par défaut.
Vous voyez java dans une stage 3 de gentoo ? Je ne parle même pas de LFS… Sans compter qu'une JVM c'est quand même lourd (sans troller) et tout le monde n'en veut pas sur son système. Et que dire de l'ombre d'oracle qui plane derrière java ? (ah zut on est lundi ?)
[^] # Re: Ant ?
Posté par daemontux . Évalué à 2.
Et les fichiers XML de 50000 lignes c'est à se flinguer.
[^] # Re: Ant ?
Posté par Sébastien Le Ray . Évalué à 0.
[^] # Re: Ant ?
Posté par barmic . Évalué à 6.
\tcmd1
\tcmd2
C'est tout de même vachement simple comme syntaxe. Après les commandes, c'est pas lié à make, mais à ce que tu veut faire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ant ?
Posté par Bruno Michel (site web personnel) . Évalué à 0.
[^] # Re: Ant ?
Posté par barmic . Évalué à 7.
Faut le savoir c'est simple, oui c'est une limitation à la noix, mais c'est trivial à utiliser, vérifier.
Les bons IDE, permettent à ceux qui font de l'expendtab (comme moi) de ne pas le faire pour les fichiers [mM]akefile.
Les nom de fichiers sans espaces je considère que c'est une bonne pratique générale en informatique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ant ?
Posté par patate . Évalué à 1.
Moi aussi, par confort, mais faut quand même reconnaître que c'est une limitation stupide avec laquelle il faut composer. Si on va par là, on peut limiter les noms des fichiers à 8 caractères et une extension en trois lettres.
[^] # Re: Ant ?
Posté par barmic . Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ant ?
Posté par daemontux . Évalué à 2.
Bon OK ça permet de mettre deux fichiers cote à cote ce qui est pratique quand on fait un diff ou autre, mais 80 caractères je trouve ça trop court, se limiter à 100 ou 120 m'éviterait souvent de devoir passer à la ligne juste pour ça.
Après pour les gens qui codent en C et qui suivent la tradition d'avoir des noms de fonctions/variables les plus courts et cryptiques qui soient (genre appeler la moitié de ses variables "buf") c'est peut-être trop long, comme pour les dev C#/Java qui font quasiment des phrases en CamelCase c'est peut-être trop court, mais en tout cas on devrait définir cette limite selon les besoins d'aujourd'hui plus que selon la largeur des terminaux d'il y a 30 ans.
[^] # Re: Ant ?
Posté par barmic . Évalué à 6.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ant ?
Posté par Almacha (site web personnel) . Évalué à 3.
- le manque d'indépendance de la plateforme
- les choses horribles du genre de la ligne DEPS donnée en exemple
Problèmes qui sont résolus par ant, mais pas par le Repo apparemment.
Cela dit, je reconnais que je n'ai utilisé ant que pour des projets java et que je n'ai pas d'avis sur son adaptation pour d'autres langages.
À mon avis avec Make on est typiquement dans la situation où on a :
- un outil historique que tout le monde sait utiliser mais qui a plein de défauts (make)
- beaucoup d'outils plus modernes n'ayant pas ces défauts (ant et tous les autres), mais du fait de leur multitude, aucun de s'impose vraiment et la seule référence que tout le monde continue à utiliser car dénominateur commun est le logiciel historique
[^] # Re: Ant ?
Posté par barmic . Évalué à 3.
J'ai vraiment pas envie de me farcir un build.xml, mais rien que dans le monde Java il y a une multitude de builder : buildr, Ivy, Grape,...
Je ne les ai pas essayé parce que je suis très bien avec maven.
Pour make, je n'ai pas encore trouvé de remplaçant qui me satisfasse (quelque chose de vraiment indépendant d'un langage, qui soit simple, flexible). Le seul qui pourrait peut être le remplacer c'est omake, qui est plutôt une évolution de make.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ant ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Et si je l'utilise pour quelques projets en LaTeX, j'avoue que j'en suis quand même pas fan. Surtout que la manière dont il analyse les fichiers est obscure (il est supposé ne pas recompiler si tu ne changes que les commentaires par exemple), et qu'il ignorait dans mon cas la bibliographie de mon projet, refusant d'appeler bibtex tant que le nom de fichier n'était pas le même que celui du fichier tex principal…
[^] # Re: Ant ?
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Il me semble qu'il y a deux systèmes simples pour voir si un fichier a été modifié, la date et un checksum. Tout autre système devient intrusif. Il faudrait pouvoir choisir selon le type de fichier. C'est un peu ce que propose cfengine dans ses règles de "copy".
# scons ?
Posté par Troy McClure (site web personnel) . Évalué à 10.
Personnellement ,si il y a un programme qui pourrait remplacer Make , c'est SCons à mon avis. (ou waf)
En tout cas, ça m'étonnerait que l'exemple donné dans la news puisse convaincre une personne de quitter make pour redo ! La lisibilité et la concision du truc est pour le moins pas très impresionnante.
[^] # Re: scons ?
Posté par swilmet . Évalué à 4.
CMake, et sans doute SCons et Waf aussi (mais je n'en suis pas sûr) ¹, sont des générateurs de Makefile, et donc make est quand même utilisé par après.
Donc ces outils ne se situent pas au niveau de make, mais des autohell autotools.
Si les remplaçants de make commencent à devenir populaire, on pourrait imaginer que CMake et compagnie supportent plusieurs « make-like » en sortie.
¹ Pour moi SCons et Waf sont des alternatives à CMake et aux autotools, pas à make.
[^] # Re: scons ?
Posté par Keph (site web personnel) . Évalué à 5.
[^] # Re: scons ?
Posté par swilmet . Évalué à 2.
Mais il me semble que SCons et Waf offrent plus ou moins le même genre de fonctionnalités que CMake, dont notamment le fait de vérifier si la compilation est possible et de paramétrer cette compilation (suivant le système et les choix de l'utilisateur), ce que ne permettent pas directement make ou redo.
[^] # Re: scons ?
Posté par swilmet . Évalué à 1.
Ça confirme bien ce que je dis.
[^] # Re: scons ?
Posté par calandoa . Évalué à 2.
Make répond à ces fonctionnalités! Si il manque un fichier ou une « target », make le remonte ; d'autre part il est possible de choisir les actions a effectuer en fonction de variables dépendantes du système ou de la ligne de commande. Je ne vois pas vraiment où tu veux en venir avec cette définition... tu as un exemple précis?
[^] # Re: scons ?
Posté par GeneralZod . Évalué à 3.
Par rapport à CMake, il a l'avantage de reposer sur un langage de script complet et flexible (Python/ersatz utilisé par CMake), de former un ensemble cohérent (CMake est un générateur de projets) mais il a un défaut majeur par rapport à GNU Make, il gère horriblement mal la parallélisation des tâches.
Waf me semble plus à même dans la même catégorie de rivaliser avec Make, il gère mieux la parallélisation (donc nettement plus rapide), une API plus familière aux Pythonistas et une configuration plus souple. Le projet est plus dynamique que Scons, mais un peu brouillon (beaucoup de changement d'APIs)
Personnellement, même si je préfère l'approche Scons/Waf, j'ai fait le choix de CMake pour les raisons suivantes principalement pour le fait qu'il soit self-contained, très rapide (le jour et la nuit par rapport à Scons), et qu'il dispose d'une large collection de modules pas loin de rivaliser avec autotools. Certes, CMake a un langage de script pourri (mais simple), certes, c'est un générateur de projets mais GNU Make est un composant éprouvé, CMake suppléant à ses défauts, ça en fait une solution tout à fait acceptable dans un cadre industriel ou libre.
[^] # Re: scons ?
Posté par Troy McClure (site web personnel) . Évalué à 4.
Ah ? c'est la premiere fois que j'entends dire ça, perso quand je fais un scons -j4 sur un quad-core il n'a aucun probleme pour faire bosser les 4 coeurs à 100%. La vitesse est effectivement un souci sur les scripts un peu gros, mais par contre il garantie à 100% d'avoir un build correct.
Sinon une killer feature de scons je trouve, c'est le cache des resultats intermediaires de compilation, ça remplace ccache et c'est plus général.
[^] # Re: scons ?
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: scons ?
Posté par GeneralZod . Évalué à 4.
Par contre, les générateurs constituent un cas particulier, il vaut mieux les développer en C++ (typiquement, une classe qui hérite de cmGlobalGenerator), sinon, ce n'est pas maintenable à long terme. C'est pas bien compliqué, CMake est très architecturé et le code source extrêmement bien documenté (tu peux générer une doc doxygen de l'API relativement à jour).
Le seul point négatif de CMake est son langage de script pourrave, ajouter un nouveau langage, le support d'une bibliothèque est super simple parce qu'on dispose déjà des commandes qui vont bien. C'est pas forcément le cas pour écrire un générateur.
[^] # Re: scons ?
Posté par swilmet . Évalué à 1.
if (blabla)
endif (blabla)
À part ça je trouve que ça va.
[^] # Re: scons ?
Posté par GeneralZod . Évalué à 2.
[^] # Re: scons ?
Posté par swilmet . Évalué à 1.
Mais alors que reproches-tu à la syntaxe de CMake ?
[^] # Re: scons ?
Posté par GeneralZod . Évalué à 2.
Certes, pour un DSL, c'est pas trop mal foutu mais parfois un langage plus évolué (python, lua ou même javascript) faciliterait bien la vie des développeurs.
# J'aimerais des explications sur
Posté par totof2000 . Évalué à 9.
Je trouve que la syntaxe de make plutot claire (je ne parle pas des extensions GNU que j'évite d'utiliser pour rester portable).
sinon, devoir installer Python pour compiler un pauvre programme C ... euh ... Jen e sais pas pourquoi mais ça me gène.
[^] # J'aimerais des explications sur
Posté par totof2000 . Évalué à -2.
[^] # Re: J'aimerais des explications sur
Posté par BFG . Évalué à 4.
[^] # Re: J'aimerais des explications sur
Posté par Kangs . Évalué à 5.
[^] # Re: J'aimerais des explications sur
Posté par BFG . Évalué à 2.
[^] # Re: J'aimerais des explications sur
Posté par Kangs . Évalué à 3.
[^] # Re: J'aimerais des explications sur
Posté par totof2000 . Évalué à 3.
[^] # Re: J'aimerais des explications sur
Posté par BFG . Évalué à 3.
J'avais lu qu'on ne pouvait moinsser une personne que 2 fois par jour, mais templeet n'est pas propice à la vérification de cette information. Pensez-vous que templeet serait plus adapté pour écrire des Makefiles ?
[^] # Re: J'aimerais des explications sur
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: J'aimerais des explications sur
Posté par totof2000 . Évalué à 2.
[^] # Re: J'aimerais des explications sur
Posté par totof2000 . Évalué à 5.
Pas exactement : plutot "nul besoin d'une usine à gaz comme Python (ou Java, ou Ruby, ou n'importe quel langage "bloatware") pour développer en C.
t votre deuxième message : "c'est bien, on peut utiliser ruby pour compiler du C"...
No, je dis qu'un remplaçant à Make pour Ruby existe déjà. Mais je ne m'en servirais pas pour écrire un programme C (j'aime pas multiplier inutilement les dépendances). Par contre ça peut être utile si on veut intégrer du C à un prog. Ruby (ou vice-versa, et vous pouvez remplacer Ruby par Python avec l'outil adéquat).
L'avantage de Make c'est qu'il est dispo sur tous les Unix dignes de ce nom.
[^] # Re: J'aimerais des explications sur
Posté par 태 (site web personnel) . Évalué à 1.
Ça existait aussi déjà en python, ça s'appelle scons !
Morale 1 : Si ça existe en ruby, ça existait avant en python et inversement...
Morale 2 : Les pythonneux ne suivent pas la devise de python : "il n'y a qu'une bonne façon de faire les choses".
[^] # Re: J'aimerais des explications sur
Posté par BFG . Évalué à 2.
Mais si, Ruby est la _mauvaise_ façon de faire les choses. Donc pas de conflit avec la règle.
[^] # Re: J'aimerais des explications sur
Posté par Xowap (site web personnel) . Évalué à 5.
[^] # Re: J'aimerais des explications sur
Posté par totof2000 . Évalué à 2.
[^] # Re: J'aimerais des explications sur
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: J'aimerais des explications sur
Posté par GeneralZod . Évalué à 7.
[^] # Re: J'aimerais des explications sur
Posté par totof2000 . Évalué à 2.
- j'installe l'OS
- je lance la commande => pouf,pouf, ça marche sans rien installer d'autre.
à la limite, cas 2:
-j'installe l'os (version minimale"
-je lance la commande => PAF ca marche pas.
- j'installe 1 paquet make
- je lance =>pouf ça marche.
[^] # Re: J'aimerais des explications sur
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: J'aimerais des explications sur
Posté par totof2000 . Évalué à 3.
[^] # Re: J'aimerais des explications sur
Posté par lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: J'aimerais des explications sur
Posté par El Titi . Évalué à 0.
[^] # Re: J'aimerais des explications sur
Posté par Psychofox (Mastodon) . Évalué à 3.
depuis l'arborescence du dvd d'install de Solaris 10 :
# pkginfo -d . | grep -i python
GNOME2 SUNWPython The Python interpreter, libraries and utilities
GNOME2 SUNWPython-devel The Python interpreter, libraries and utilities - development files
GNOME2 SUNWPython-share The Python interperer, libraries and utilities - platform independent files
Bon cela-dit, je ne vois pas trop ce qu'il vient faire dans le cluster de packages "GNOME2", qui est effectivement, rarement installé par les admins par défaut.
[^] # Re: J'aimerais des explications sur
Posté par Antoine . Évalué à 4.
$ head /usr/bin/pkg
#!/usr/bin/python2.6
#
# CDDL HEADER START
#
# The contents of this file are subject to the terms of the
# Common Development and Distribution License (the "License").
# You may not use this file except in compliance with the License.
#
# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
# or http://www.opensolaris.org/os/licensing.
[^] # Re: J'aimerais des explications sur
Posté par Antoine . Évalué à 10.
Voici le manuel d'un "truc simple comme Make", auquel il est de rigueur d'ajouter le manuel d'un "truc simple comme bash" et celui d'un "truc simple comme autotools". Tant qu'à se farcir une doc aussi touffue et un système aussi complexe, autant apprendre un langage de programmation généraliste qui te servira à autre chose qu'à compiler d'autres programmes. Enjoy.
http://www.gnu.org/software/make/manual/make.html
Après on s'étonne qu'un pauvre petit logiciel style Hello World nécessite 3 Gb de dépendances pour être compilé et/ou exécuté.
En même temps je sais pas pour toi, mais je n'ai pas acheté un ordinateur pour exécuter des Hello World. Sinon un vieil Amstrad CPC te suffira.
[^] # Re: J'aimerais des explications sur
Posté par Bruno Michel (site web personnel) . Évalué à 3.
La version actuelle de redo est en python, mais son auteur indique qu'à terme, il compte bien le réécrire en C.
[^] # Re: J'aimerais des explications sur
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
Pourquoi ? Il veut rajouter des bugs pour gagner un semblant de portabilité et deux micro-pouillèmes de secondes lors de la compilation de projets de 1000 fichiers ?
Encore un UUOC (Useless Use Of C)…
[^] # Re: J'aimerais des explications sur
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Même sans aller jusque là, construire un makefile qui marche sur juste linux-86 et openbsd-sparc64, c'est parfois un peu rude... surtout à 11h du soir...
[^] # Re: J'aimerais des explications sur
Posté par barmic . Évalué à 8.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Améliorer make
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Le problème que l'on rencontre le plus souvent est la tabulation obligatoire remplacée par des espaces. J'ai vu un sous-traitant passer deux semaines sur cette erreur avant que je le dépanne.
Une suggestion serait d'améliorer la détection et les messages d'erreur de make ou de faire un programme de vérification à la façon du validator du W3C ou de nsgmls.
[^] # Re: Améliorer make
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# CMake ?
Posté par khivapia . Évalué à 5.
Personnellement, si il y a un programme qui pourrait remplacer Make , c'est CMake à mon avis.
La syntaxe est facile à appréhender, il est utilisé pour de très larges projets (KDE entre autres, qui avait hésité à utiliser SCons http://lwn.net/Articles/188693/ ), est multiplateforme, intègre de nombreuses interfaces vers des systèmes de compilation spécifiques à certaines bibliothèques, par exemple des projets basés sur Qt...
[^] # Re: CMake ?
Posté par EdB . Évalué à 9.
CMake remplace plutôt les autotools
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: CMake ?
Posté par Vincent Danjean . Évalué à 2.
Make/autotools est un outil complexe à prendre en main (si on s'écarte des cas de base) mais il est assez puissant pour faire à peu près tout ce qu'on veut. Après, c'est comme partout : on peut écrire du code propre ou pas (je parle du code Makefile et m4).
[^] # Re: CMake ?
Posté par rewind (Mastodon) . Évalué à 3.
puis :
configure_file(biblio.pc.in biblio.pc)
De rien :)
[^] # Re: CMake ?
Posté par Vincent Danjean . Évalué à 1.
Ce que je cherche à faire, c'est de faire calculer à CMake ce qu'il faudra dans le biblio.pc en fonction des bibliothèques trouvées sur le système (avec un .pc ou directement avec les flags -l.. -L.., -I...) et en fonction de la façon dont je l'utiliserai (CMake ne peut pas savoir si, en créant ma bibliothèque, il doit mettre les bibliothèques dans la partie private (ie nécessaire uniquement pour le link static) ou public (nécessaire dans tous les cas) donc, si, dans la solution proposée, je n'ai pas à fournir cette info, c'est que ce n'est pas ce que je cherche).
Pour les autotools, j'ai fait ça :
http://git.ligforge.imag.fr/?p=users/vdanjean/tools/autolibs(...)
Pour CMake, je ne vois pas comment faire si on veut garder les routines existantes de CMake pour la détection des bibliothèques (et si on les remplace, ça n'a aucun intérêt par rapport aux autotools)
[^] # Re: CMake ?
Posté par rewind (Mastodon) . Évalué à 2.
En fait, je me demande s'il n'y aurait pas une négation en trop dans "si, dans la solution proposée, je n'ai pas à fournir cette info, c'est que ce n'est pas ce que je cherche" ? Si c'est le cas, je ne vois pas en quoi ton script y répond. Si ce n'est pas le cas, alors CMake peut le faire aussi.
[1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:F(...)
[^] # Re: CMake ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
En pratique, se baser sur ce qu'on peut trouver sur une machine est rarement une bonne idée :
. ça empêche la compilation croisée, ou du moins la compilation sur une machine rapide pour une utilisation sur une cible différente ;
. les empaqueteurs des autres systèmes ou distributions vont de toutes façons virer tout ça, pour compiler dans un caisson le plus étanche possible.
Ce qu'il faut c'est avant tout que l'auteur spécifie correctement les dépendances dont il a besoin en fonction des options choisies, et que le répertoire où celles-ci sont installées soit paramétrable.
[^] # Re: CMake ?
Posté par M . Évalué à 2.
C'est clair que moi aussi j'ai été dessus par CMake.
Des que tu veux faire un truc un peu complexe on peut tomber sur un cratère (ie c'est pas possible).
Quand aux autotools c'est une utsine a gaz qui produit des trucs imbitable. Leur configure pour des raison de portabilité est très moche.
Les Makefile générer ne sont pas mieux.
Et pour couronner le tout plein de gens font des trucs louche avec autotools.
[^] # Re: CMake ?
Posté par Moonz . Évalué à 3.
En plus de ne pas être portable. Par exemple, recompiler libical sous MacOS X nécessite de modifier le configure à la main, malgré qu’il soit généré par autohell.
[^] # Re: CMake ?
Posté par BFG . Évalué à 4.
C'est à mon avis une mauvaise approche. Chaque type de projet a ses fonctions spécifiques, et le plus petit dénominateur commun peut-être difficile à déterminer. De plus, l'outil doit génerer des sorties compliquées, à adapter au gré des versions des cibles (les IDEs)
QMake génère aussi des projets d'IDE et des Makefiles, mais il est incapable de rajouter des taches de compilation supplémentaires pour autres choses que make ! Je ne parle même pas de la compilation croisée.
Les systèmes de compilations devraient au contraire se concentrer sur le centre de leur activité : gérer la compilation. Et ce serait plutôt à l'IDE de s'adapter au systèmes de compilations. Le "I" de IDE signifie "Integrated", l'IDE ne devrait rien faire de plus que lier ensemble éditeur, débugger, système de compilation, etc.
# Fuyez !
Posté par Xowap (site web personnel) . Évalué à 10.
AAAAAAAAAAAH
Fuyez ! Fuyez ! Tant que vous le pouvez encore fuyez !
Ceux qui ont un jour utilisé qmail me comprendront...
[^] # Re: Fuyez !
Posté par reno . Évalué à 2.
[^] # Re: Fuyez !
Posté par Xowap (site web personnel) . Évalué à 10.
En fait, qmail est tellement secure qu'il se torche le cul avec les conventions de placement de fichiers, et met tout dans /var/qmail. Tu peux pas le changer, c'est hardcodé (sinon ça serait pas secure).
Ensuite, le principal facteur de sécurité est le gros manque de fonctions, c'est à dire qu'un qmail brut n'est capable que de délivrer les mails dans les répertoires perso des utilisateurs système. Il n'y a pas de configuration possible, ça serait pas secure. (les seuls fichiers de "configuration" sont quelques détails qui contiennent uniquement la liste des utilisateurs ou les domaines à relayer).
S'ajoute à cela la licence jusqu'à récemment non libre, qui fait qu'on ne pouvais pas redistribuer le code source modifié. Résultat, il n'y a pas eu de fork pour ajouter des fonctionalités *. Donc si tu te retrouves avec des vrais besoins (gérer plusieurs domaines, avoir des utilisateurs non système, ...), t'es obligé d'y aller avec une mixture de logiciels externes (vpopmail, qmailadmin par exemple) + de patchs trouvés au hasard sur des mailing lists * (patchs étant incompatibles entre eux, il faut bien entendu faire l'adaptation soi même).
Finalement, ça fait une masse d'ajouts de provenance plus ou moins douteuse, dont on n'a pas de visibilité sur les bugs, et encore moins sur les failles de sécurité. Sans oublier le fait qu'à cause de licence et de la maltraitance des conventions unix, qmail n'est pas packagé dans les distributions majeures. Et comme tout le monde le sait, ne pas installer un logiciel en utilisant le système de paquets revient à s'exposer à de nombreux ennuis...
En bref, qmail lui même n'a pas de problèmes de sécurité, mais si tu veux l'utiliser en production tu va devoir choisir entre la sécurité et les fonctionnalités. Et en fait, sauf à mettre en place un relais pour spammeur, tu n'a pas le choix. Donc qmail est complètement impossible à maintenir, en plus de t'obliger à y rajouter des failles de sécurité et des bugs échapants à la loi de Torvalds, au prix d'une grosse prise de tête.
Moralité : fuyez :)
* Ces dernières années on a vu un fork majeur et des compilations de patchs se former, mais qmail n'est plus à ses heures de gloire, ces éléments sont maintenus en pointillets si maintenu, et l'origine des modifications reste toujours aussi douteuse.
[^] # Re: Fuyez !
Posté par rhizome . Évalué à 2.
... et daemontools :(
# Y'en a déjà des kilos...
Posté par wahnby . Évalué à 0.
Mais il semble y avoir un consensus dans le monde linux autour de make mais surtout des autotools de la mort.
[^] # Re: Y'en a déjà des kilos...
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Ça ne veut pas forcément dire que redo va devenir l'équivalent de git, mais l'argument qu'il y a déjà plein d'outils pour faire ça n'est pas suffisant pour le rejeter.
[^] # Re: Y'en a déjà des kilos...
Posté par wahnby . Évalué à 1.
Mais il se trouve qu'il y a une longue histoire autour de la gestion de version. Il y a eu rcs puis cvs puis svn plus git/mercurial et d'autres. Et a chaque fois les développeurs ont migré en masse.
Pour ce qui est de autotools/make il y a eu des tas d'alternatives bien meilleures et la majorité des développeurs n'ont pas voulu migrer.
[^] # Re: Y'en a déjà des kilos...
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Il faut vraiment un outil qui à la base ne pense pas pour un langage.
# make ?
Posté par M . Évalué à 9.
Le pb c'est que les gens veule un truc plus haut niveau : filer une liste de fichiers a compiler, des options de génération (compil/link) et éventuellement faire des test dynamique sur les dépendance (version des lib, support de tel fonction, ...). Et aussi avoir une GUI a la kconfig, pour permettre de sélectionner des options de config.
C'est ce que font les autotools, mais franchement je trouve qu'ils sont une usine a gaz (makefile générer inbitable, pb de cross compilation, trop complex (les devs ne comprenne pas forcement ce qu'ils font)). Je ne parle même pas du libtool qui vient avec.
Il y a cmake, mais la derniére fois que j'ai regardé ca ma pas convaincu.
ps :
redo-ifchange $1.c
gcc -MD -MF $3.deps.tmp -c -o $3 $1.c
DEPS=$(sed -e "s/^$3://" -e 's/\\//g' <$3.deps.tmp)
rm -f $3.deps.tmp
redo-ifchange $DEPS
et ben ca m'a pas l'air très simple
[^] # Re: make ?
Posté par Jux (site web personnel) . Évalué à 3.
include ../../../Make.inc
TARG=container/vector
GOFILES=\
intvector.go\
stringvector.go\
vector.go\
include ../../../Make.pkg
http://golang.org/doc/code.html
[^] # Re: make ?
Posté par barmic . Évalué à 2.
SRC=$(wildcard *.c)
OBJ=$(SRC:.c=.o)
EXE=monprog
.PHONY: clean mrproper all
all: $(EXE)
$(EXE): $(OBJ)
gcc $^ -o $@
%.o: %.c
clean:
rm $(OBJ)
mrproper: clean
rm $(EXE)
Ou à peu près et je peux modifier mes options de compilation soit en dur dans le makefile soit avec des variables d'environnement.
Et faire de même avec go n'est pas compliqué.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: make ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: make ?
Posté par barmic . Évalué à 1.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: make ?
Posté par auve . Évalué à 3.
Euh, si tu ajoutes une version correcte de la fonctionnalité demandée par Bruno (dépendance vers les headers utilisés par un .c) à un Makefile aussi simple, ça devient de loin la partie la plus compliquée...
[^] # Re: make ?
Posté par barmic . Évalué à 1.
https://yanopaste.jujunie.com/index.php?id=20110117085221_20(...)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: make ?
Posté par barmic . Évalué à 1.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: make ?
Posté par benja . Évalué à 1.
http://mad-scientist.net/make/autodep.html pour les curieux.
[^] # Re: make ?
Posté par M . Évalué à 2.
Mais pour en avoir fait une au boulot (pour un projet de plusieurs milliers de fichiers) et ben je regrette de n'avoir pas pu utiliser une autre option a l'époque.
Le code de la template est plein de magic make incompréhensible. Des qu'il faut modifier le comportement, c'est la galère. Ca devient un truc pas maintenable, compris par quelques gurus.
On ne fait pas de make recursif, chaque sous projet inclue ses makefiles (avec la commande include de make). Et ben une boulette dans un sous makefile peu faire tout péter sans moyen simple de le debugger.
Les gens développant les sous projet ne sont pas familier avec make et font vite des boulettes qui fait tout planter.
Bref make c'est simple sur des petits projets. Mais sur des gros projets ou il faut gérer différentes versions de build (dans des répertoires différent), de la compilation conditionnelle, des tests dynamiques, ..., on arrive vite a devoir réinventer la roue et obtenir un truc bancale.
Et d'ailleurs il n'y a pas de solution de template makefile générique. La plus évolué étant le système du kernel Linux.
[^] # Re: make ?
Posté par benja . Évalué à 2.
GNUStep, L4/fiasco (inspirée de kbuild), Kbuild ça fait dejà 3. Viennent ensuite les ports (pkgsrc, FreeBSD, OpenBSD), les chaines de compilations emarquées, ...
s/n'y a pas/y a plein/g. Je vois mal comment cela pourrait être générique, cela démontre plustôt la souplesse de make; il y moyen de faire de trucs propre, aussi ;) .
[^] # Re: make ?
Posté par M . Évalué à 2.
Je vois mal comment cela pourrait être générique, cela démontre plustôt la souplesse de make;
Certes mais tout les projets ne veulent/peuvent pas avoir des experts make dans leur équipes.
Compte le nombre de gens qui connaisse bien les templates que tu as cité (ie seront corrigé un bug dedans, ajouter des nouvelles fonctionnalitées).
il y moyen de faire de trucs propre, aussi ;) .
Comme dans a peu pres tout les langages.
[^] # Re: make ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Si ça peut intéresser quelqu'un en voici le source : http://pjarillon.free.fr/docs/mkmkf.c
[^] # Re: make ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Bah, même pour la gestion des dépendances, make n'est pas si bien que ça. Ce n'est pas facile d'avoir un Makefile générique qui sache recompiler juste les fichiers nécessaires quand un .h a été modifié. Ou qui ne refasse que la phase d'édition de liens quand on change LDFLAGS.
[^] # Re: make ?
Posté par benja . Évalué à 1.
un truc du genre ?
unlink:
find . -name \*.a -o -name $(EXE) | xargs rm -f
[^] # Re: make ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
mon_executable: $(OBJS) $(LDFLAGS)pour indiquer à make qu'il doit reconstruire 'mon_executable' si LD_FLAGS change. Mais je ne sais pas faire ça sans avoir à mettre LDFLAGS dans un fichier à part.
[^] # Re: make ?
Posté par benja . Évalué à 2.
[^] # Re: make ?
Posté par M . Évalué à 2.
Après s'ils sont passé par paramètre c'est la misère.
[^] # Re: make ?
Posté par BFG . Évalué à 2.
# ... as usual
Posté par Jul (site web personnel) . Évalué à 8.
Pour preuves, on utilise toujours ISC bind qui est effectivement une horreur de conf et de code.
(ouahouh, \o/ j'ai réussi un point GodWin en début de thread)
[^] # Re: ... as usual
Posté par Xowap (site web personnel) . Évalué à 1.
# Et les ficher Jam ?
Posté par Anonyme . Évalué à 1.
http://psycle.svn.sourceforge.net/viewvc/psycle/branches/boh(...)
jam semble performant. Une autre page montre les diverses fonctionnalités des systèmes de build:
http://www.scons.org/wiki/SconsVsOtherBuildTools
Je ne sais pas si certains d'entre vous ont utilisé jam, mais si oui, j'aimerais bien avoir leur(s) avis.
# J'attends désespérément un moteur de production potable...
Posté par small_duck (site web personnel) . Évalué à 6.
Les solutions modernes, telles Ant ou Rake, sont souvent soit horriblement verbeuses, soit très légo: l'on assemble des blocs trouvés sur le Net, et si l'on a besoin de quelque chose d'un peu ésotérique, c'est l'horreur. Ceux qui me déplaisent le moins sont Scons et OMake, ce dernier, écrit en OCaml, étant mon favori dans mes projets perso.
Comme d'ailleurs les langages de programmation, tous ces outils ont été écrits pour résoudre des problèmes particuliers, et je crains qu'il n'existe pas de solution vraiment universelle, contrairement à la gestion de sources, par exemple, où Git et Mercurial proposent un modèle très solide.
Snif.
[^] # Re: J'attends désespérément un moteur de production potable...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Une petite idée vient de me passer en tête et je pense qu'il faudrait un truc équivalent à cfengine mais dédié pour la compilation. cfengine est écrit en C, son fichier de config est humain, il s'adapte aux différentes architectures via des règles et des classes et on envoi facilement une commande, pas forcément du bash.
[^] # Re: J'attends désespérément un moteur de production potable...
Posté par benja . Évalué à 0.
Je penses que tu confonds avec ocamlbuild, inclus au language ocaml depuis la version 3.10. C'est du très bon effectivement, mais il faut pouvoir aussi mettre les mains dans le cambouis pour faire des trucs exotiques et la documentation n'est pas, comment dire, abondante...
OMake est encore un exemple de template-Makefile (à la GNUStep-make, kbuild, ...).
[^] # Re: J'attends désespérément un moteur de production potable...
Posté par auve . Évalué à 1.
[^] # Re: J'attends désespérément un moteur de production potable...
Posté par benja . Évalué à 1.
[^] # Re: J'attends désespérément un moteur de production potable...
Posté par benja . Évalué à 1.
# Rien ne vaut un bon benchmark bien viril
Posté par calandoa . Évalué à 3.
http://psycle.svn.sourceforge.net/viewvc/psycle/branches/boh(...)
[^] # Re: Rien ne vaut un bon benchmark bien viril
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien ne vaut un bon benchmark bien viril
Posté par Moonz . Évalué à -1.
[^] # Re: Rien ne vaut un bon benchmark bien viril
Posté par Antoine . Évalué à 7.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.