Les avantages de ce type de compilation sont les mêmes que pour un seul fichier et se défendent assez facilement dans certains cas (et je pense que G'MIC/CImg fait partie de ces cas).
Tiled est un logiciel à part entière qui sert à fabriquer des cartes/niveaux à base de tuiles. Ce n'est pas une lib. Il y a une lib mais qui est utilisée principalement par le logiciel lui-même. En tout cas, moi je ne l'utilise pas, j'ai fait ma propre lib pour lire le format produit par le logiciel. Et j'utilise le logiciel pour faire mes cartes. Ce logiciel est très utilisé par tout un tas de jeux.
il ne semble pas que j'ai vu d'autre créateur utiliser de licence libre.
L'auteur de Tiled (sous licence GPL) espère aussi gagner suffisament d'argent pour vivre du développement de Tiled. Il explique son choix. Pour l'instant, il essaie juste de financer quelques jours de dev par semaine, mais il en est encore loin.
Oui mais est-ce qu'avec un tel système, tu n'es pas obligé de déclarer deux fois tes dépendances : une fois dans CMake et une fois dans tes fichiers de dépendances ?
Ce que tout le monde dis, c'est qu'on s'en fout du langage. Tu t'interdit un outil avec pour principal voir seul prétexte, il n'est pas dans mon langage c'est pas sérieux. Alors que tout le monde s'en fout.
On s'en fout du langage mais quand même personne n'utilise un outil d'un autre langage.
L'argumentaire de Firwen dans l'autre journal n'a pas eu l'air de te convaincre non plus donc, je ne vais même pas essayer d'aller plus loin. Je pense qu'on a des points de vue différent sur la question et que ça ne sert à rien de redire encore et encore les mêmes choses.
AMHA il vaut mieux avoir un outil qui tourne sur nodejs que pas d'outils du tout, mais après c'est toi qui vois.
Pour l'instant, le choix, il est entre rien du tout et rien du tout surtout.
Ça a l'air intéressant. Comme je le vois, c'est une sorte de surcouche à CMake pour automatiser un peu plus les tâches de gestion de dépendances. Du coup, c'est assez invasif je trouve (par exemple, commandes à utiliser à la place des commandes habituelles).
On parle de gestionnaire de dépendances là, pas de machine virtuelle… Je t'invite à lire la liste plus haut et à m'expliquer pourquoi tous les dev dans tous les langages choisissent le dit langage pour implémenter un gestionnaire de dépendance, ça m'intéresse.
Je continue (j'en ai encore quelques uns) ou c'est bon ? Tu vas m'expliquer que tous ces développeurs ne sont que des neuneus et qu'ils ont tous implémentés un gestionnaire de dépendance pour leur langage dans leur langage mais qu'ils ont tous eu tort et qu'ils auraient dû n'avoir qu'un seul outil ? Et bien, personnellement, je préfère être du côté de tous ces braves idiots et considérer qu'un outil en C++ pour gérer du C++, c'est juste du bon sens.
Après, peut-être que certains de ces outils gèrent autre chose que leur propre langage, mais c'est quand même pas la norme hein… et ce n'est pas l'utilisation réelle qu'en font les développeurs. Peut-être aussi parce que la plupart des dev n'ont pas envie d'avoir une deuxième pile logicielle pour gérer les dépendances.
Justement on est d'accord, il ne faut pas que l'outil s'intéresse à autre chose qu'à la construction de projet.
La construction de projet dépend du langage que tu utilises ! Donc si tu fais de la construction de projet générique, tu fais bien des dizaines de choses différentes, même si de loin dans le brouillard ça se ressemble.
Un petit logiciel qui travaillait sur des distances d'images en C++ avec Qt, boost et eigen, ça te va ?
Chercher un outil qui fait tout, il y a de grandes chances que ça ne fasse rien de bien. Sinon, juste par curiosité, tu as déjà fait un code en C++ avec des dépendances ?
Ya pas de raisons que les outils diffèrent selon le langage de ton programme, et pas de raisons que les outils que tu utilises soient nécessairement codés dans le même langage.
Il n'y a pas de raison mais c'est quand même plus crédible non ? Un outil de ce genre qui ne serait pas codé dans le langage qu'il est censé gérer, ça fait pas très crédible à mon sens. Et quand on regarde les autres langages, ils ont quasiment tous des outils codés dans le langage lui-même pour gérer ce genre de choses (Java, Python, Ruby, Go, même PHP). Pourquoi le C++ n'aurait pas droit à un outil dédié codé en C++ ?
Tout ce que tu décris, c'est tout ce que je fais à la main et que j'aurais envie d'automatiser. Oui, on peut écrire dans un README qu'il faut telle ou telle bibliothèque. Maintenant, si je peux l'écrire dans un fichier de config et que ça va me le chercher tout seul (si ce n'est pas déjà sur le système), ça sera quand même plus facile, ça facilitera les contributions, ça permettra de ne plus faire ces tâches ingrates. Quasiment tous les langages ont ça, quasiment tous les langages ont un dépôt central pour plein de bibliothèques voire toutes les bibliothèques du langage. Tous sauf C++. Je n'ai pas l'impression que ça pose beaucoup de problème dans les autres langages.
Après, pour les gens qui utilisent une version spécifique, ça peut avoir un intérêt. Et ça n'empêche pas de suivre l'évolution des bibliothèques concernées ! Pour moi, ça veut juste dire : avec telle version, ça marche, c'est validé.
Je l'attendais. Maven ne convient pas parce que C++ a beaucoup de spécificités. En plus, il est quand même plus naturel d'avoir un outil pour C++ codé en C++ (eat your own dog food).
Je me demande quelle tête ferait un dev Java si je lui proposais d'utiliser CMake pour compiler son code…
Chez moi (Debian), installer dans /usr/local ne demande pas les droits root, juste d'être dans le groupe staff (je bénis les développeurs Debian tous les jours pour ce petit truc à la con). Ceci dit, ta remarque est pertinente, on pourrait très bien définir des répertoires d'installation locaux.
Il faut recompiler le programme en fonction de la machine cible pour pouvoir agencer certaines données de la manière la plus optimisée possible. La compilation serait faite sur la machine de l'utilisateur final.
Est-ce que ça en vaut bien la peine ? Je ne le pense pas. Es-tu sûr que le gain va être perceptible sur la plupart des programmes ? Je ne le pense pas. D'autre part, la mode est à la recompilation reproductible, donc avoir des options de compilations différentes suivant les machines, ce n'est pas top de ce point de vue. Enfin, il faut aussi penser à la cross-compilation (par exemple, compiler un binaire Windows depuis Linux) qui est assez compliquée par nature sans rajouter des options de compilation tordues.
il faut juste faire un wrappeur qui telechargerait le paquet manquant
Si c'était si simple, ça se saurait. En fait, si tu le fais de cette manière, il y a de fortes chances que tu aies un wrappeur pour chaque lib que tu utilises (donc du travail à faire en plus à chaque fois, pour tous les développeurs). Sans compter que pour télécharger un tarball, tu as des outils différents sous Windows et Linux (est-ce que curl existe sous Windows ?), ce qui te fait des dépendances supplémentaires pour ton projet alors que tu voudrais bien qu'un outil unique gère tout ça pour toi.
Il serait bien qu'un outil de ce type ne touche pas au système, ne demande pas des droits particulier et qu'un projet n'est pas d'effet de bord sur le reste.
Si tu veux installer localement (dans /usr/local par exemple), tu es obligé de toucher un minimum au système. Mais avoir une procédure de désinstallation propre, en revanche, serait une très bonne idée (ça manque cruellement dans CMake par exemple).
Il faut une syntaxe la plus déclarative possible tout en étant puissante.
Entièrement d'accord. Refaire un n-ième langage de configuration est sans doute une piste à éviter en priorité.
Il est intéressant de regarder gradle pour avoir un exemple de fichier parsable humainement par des outils, mais puissant.
Ça a l'air intéressant, en effet. Un peu plus puissant que du YAML (ou similaire) mais pas trop complexe. Après, il faut aimer les accolades.
Cite moi un bon IDE. La question est rhétorique, parce que chacun a son bon IDE. Et selon moi, il faut surtout permettre que l'intégration à un IDE soit facile, de manière à laisser les utilisateurs de l'IDE en question faire le travail.
la génération de «packages»: deb, rpm, setup.exe, setup.sh, superbinaireportable.zip…
Mille fois oui. Mais comme je le dis plus haut, avec des sources normalisées, ça devrait sans doute être plus facile.
un déploiement / hébergement facile des dépôts (un serveur http doit suffire).
Entièrement d'accord. J'ajouterais même, une intégration avec le système installé (histoire de ne pas télécharger un truc déjà installé localement via un paquet par exemple).
Ça oui. Il y a quelques cas connus à gérer obligatoirement. Je pense à moc, mais aussi à flex/bison.
permettre de construire des ressources autres que les exécutables, comme des images générées, de la documentation, des fichiers de configuration
Ça, ce n'est pas forcément facile, parce que souvent, la méthode de génération est propre à un outil. Mais pareil, quelques cas particuliers devraient être gérés, comme Doxygen.
s'intégrer à des outils pour faire des paquets pour les distributions
La normalisation des sources devrait permettre d'améliorer l'automatisation de création de paquet, à mon avis.
Il a fallu plus de 5 ans pour que mon logiciel trouve un mainteneur Debian, et je ne suis pas un cas isolé.
Pour le coup, je vais me mettre en mode Zenitram pour répondre à Zenitram : «tu as payé quelqu'un pour le faire ? Non, tu veux du gratuit mais tu ne veux pas payer pour ça, et tu te plains alors que personne ne te doit rien.» Je l'ai bien fait, ça va ?
[^] # Re: color2gray et organisation du code
Posté par rewind (Mastodon) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 2.
Il y a même des gens qui font plusieurs fichiers et qui compilent tout en une seule fois, en incluant tous les .cc/.cpp dans un seul fichier ! http://en.wikipedia.org/wiki/Single_Compilation_Unit
Les avantages de ce type de compilation sont les mêmes que pour un seul fichier et se défendent assez facilement dans certains cas (et je pense que G'MIC/CImg fait partie de ces cas).
[^] # Re: Un autre exemple
Posté par rewind (Mastodon) . En réponse au journal 'nal à double tranchant. Évalué à 2.
Ha oui, je comprends mieux, et je suis d'accord avec toi.
[^] # Re: Un autre exemple
Posté par rewind (Mastodon) . En réponse au journal 'nal à double tranchant. Évalué à 2.
Tiled est un logiciel à part entière qui sert à fabriquer des cartes/niveaux à base de tuiles. Ce n'est pas une lib. Il y a une lib mais qui est utilisée principalement par le logiciel lui-même. En tout cas, moi je ne l'utilise pas, j'ai fait ma propre lib pour lire le format produit par le logiciel. Et j'utilise le logiciel pour faire mes cartes. Ce logiciel est très utilisé par tout un tas de jeux.
# Un autre exemple
Posté par rewind (Mastodon) . En réponse au journal 'nal à double tranchant. Évalué à 3.
L'auteur de Tiled (sous licence GPL) espère aussi gagner suffisament d'argent pour vivre du développement de Tiled. Il explique son choix. Pour l'instant, il essaie juste de financer quelques jours de dev par semaine, mais il en est encore loin.
[^] # Re: \o/
Posté par rewind (Mastodon) . En réponse au journal Le Dessous des cartes + Creative Commons = ♥. Évalué à 2.
Il restera toujours les paparazzis…
[^] # Re: Il existe qibuild !
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Oui mais est-ce qu'avec un tel système, tu n'es pas obligé de déclarer deux fois tes dépendances : une fois dans CMake et une fois dans tes fichiers de dépendances ?
[^] # Re: m a v e n
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
On s'en fout du langage mais quand même personne n'utilise un outil d'un autre langage.
L'argumentaire de Firwen dans l'autre journal n'a pas eu l'air de te convaincre non plus donc, je ne vais même pas essayer d'aller plus loin. Je pense qu'on a des points de vue différent sur la question et que ça ne sert à rien de redire encore et encore les mêmes choses.
Pour l'instant, le choix, il est entre rien du tout et rien du tout surtout.
[^] # Re: Il existe qibuild !
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Ça a l'air intéressant. Comme je le vois, c'est une sorte de surcouche à CMake pour automatiser un peu plus les tâches de gestion de dépendances. Du coup, c'est assez invasif je trouve (par exemple, commandes à utiliser à la place des commandes habituelles).
[^] # Re: YOCTO
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Ça n'a pas l'air de gérer Windows en dehors de MingW. Je me trompe ?
[^] # Re: m a v e n
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2. Dernière modification le 09 avril 2015 à 13:52.
On parle de gestionnaire de dépendances là, pas de machine virtuelle… Je t'invite à lire la liste plus haut et à m'expliquer pourquoi tous les dev dans tous les langages choisissent le dit langage pour implémenter un gestionnaire de dépendance, ça m'intéresse.
[^] # Re: m a v e n
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 3.
Je continue (j'en ai encore quelques uns) ou c'est bon ? Tu vas m'expliquer que tous ces développeurs ne sont que des neuneus et qu'ils ont tous implémentés un gestionnaire de dépendance pour leur langage dans leur langage mais qu'ils ont tous eu tort et qu'ils auraient dû n'avoir qu'un seul outil ? Et bien, personnellement, je préfère être du côté de tous ces braves idiots et considérer qu'un outil en C++ pour gérer du C++, c'est juste du bon sens.
Après, peut-être que certains de ces outils gèrent autre chose que leur propre langage, mais c'est quand même pas la norme hein… et ce n'est pas l'utilisation réelle qu'en font les développeurs. Peut-être aussi parce que la plupart des dev n'ont pas envie d'avoir une deuxième pile logicielle pour gérer les dépendances.
[^] # Re: Des promesses...
Posté par rewind (Mastodon) . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 2.
La construction de projet dépend du langage que tu utilises ! Donc si tu fais de la construction de projet générique, tu fais bien des dizaines de choses différentes, même si de loin dans le brouillard ça se ressemble.
Et tu as utilisé Maven ?
[^] # Re: Des promesses...
Posté par rewind (Mastodon) . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 3.
Chercher un outil qui fait tout, il y a de grandes chances que ça ne fasse rien de bien. Sinon, juste par curiosité, tu as déjà fait un code en C++ avec des dépendances ?
[^] # Re: m a v e n
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 1.
Il n'y a pas de raison mais c'est quand même plus crédible non ? Un outil de ce genre qui ne serait pas codé dans le langage qu'il est censé gérer, ça fait pas très crédible à mon sens. Et quand on regarde les autres langages, ils ont quasiment tous des outils codés dans le langage lui-même pour gérer ce genre de choses (Java, Python, Ruby, Go, même PHP). Pourquoi le C++ n'aurait pas droit à un outil dédié codé en C++ ?
[^] # Re: souvenir du C
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Je doute que PKGBUILD soit multi-plateforme…
[^] # Re: heureusement, les syndicats sont là
Posté par rewind (Mastodon) . En réponse au journal sous-developpeurs-SSII. Évalué à 10.
Question subsidiaire : la CFE-CGC est-elle un vrai syndicat (au sens historique du terme) ?
[^] # Re: souvenir du C
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 3.
Tout ce que tu décris, c'est tout ce que je fais à la main et que j'aurais envie d'automatiser. Oui, on peut écrire dans un README qu'il faut telle ou telle bibliothèque. Maintenant, si je peux l'écrire dans un fichier de config et que ça va me le chercher tout seul (si ce n'est pas déjà sur le système), ça sera quand même plus facile, ça facilitera les contributions, ça permettra de ne plus faire ces tâches ingrates. Quasiment tous les langages ont ça, quasiment tous les langages ont un dépôt central pour plein de bibliothèques voire toutes les bibliothèques du langage. Tous sauf C++. Je n'ai pas l'impression que ça pose beaucoup de problème dans les autres langages.
Après, pour les gens qui utilisent une version spécifique, ça peut avoir un intérêt. Et ça n'empêche pas de suivre l'évolution des bibliothèques concernées ! Pour moi, ça veut juste dire : avec telle version, ça marche, c'est validé.
[^] # Re: m a v e n
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à -1.
Je l'attendais. Maven ne convient pas parce que C++ a beaucoup de spécificités. En plus, il est quand même plus naturel d'avoir un outil pour C++ codé en C++ (eat your own dog food).
Je me demande quelle tête ferait un dev Java si je lui proposais d'utiliser CMake pour compiler son code…
[^] # Re: Mes idées
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Chez moi (Debian), installer dans
/usr/localne demande pas les droits root, juste d'être dans le groupestaff(je bénis les développeurs Debian tous les jours pour ce petit truc à la con). Ceci dit, ta remarque est pertinente, on pourrait très bien définir des répertoires d'installation locaux.[^] # Re: Piste de réflexion
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Est-ce que ça en vaut bien la peine ? Je ne le pense pas. Es-tu sûr que le gain va être perceptible sur la plupart des programmes ? Je ne le pense pas. D'autre part, la mode est à la recompilation reproductible, donc avoir des options de compilations différentes suivant les machines, ce n'est pas top de ce point de vue. Enfin, il faut aussi penser à la cross-compilation (par exemple, compiler un binaire Windows depuis Linux) qui est assez compliquée par nature sans rajouter des options de compilation tordues.
[^] # Re: souvenir du C
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Si c'était si simple, ça se saurait. En fait, si tu le fais de cette manière, il y a de fortes chances que tu aies un wrappeur pour chaque lib que tu utilises (donc du travail à faire en plus à chaque fois, pour tous les développeurs). Sans compter que pour télécharger un tarball, tu as des outils différents sous Windows et Linux (est-ce que curl existe sous Windows ?), ce qui te fait des dépendances supplémentaires pour ton projet alors que tu voudrais bien qu'un outil unique gère tout ça pour toi.
[^] # Re: Mes idées
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Si tu veux installer localement (dans
/usr/localpar exemple), tu es obligé de toucher un minimum au système. Mais avoir une procédure de désinstallation propre, en revanche, serait une très bonne idée (ça manque cruellement dans CMake par exemple).Entièrement d'accord. Refaire un n-ième langage de configuration est sans doute une piste à éviter en priorité.
Ça a l'air intéressant, en effet. Un peu plus puissant que du YAML (ou similaire) mais pas trop complexe. Après, il faut aimer les accolades.
[^] # Re: Vous ajouteriez quoi ?
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Cite moi un bon IDE. La question est rhétorique, parce que chacun a son bon IDE. Et selon moi, il faut surtout permettre que l'intégration à un IDE soit facile, de manière à laisser les utilisateurs de l'IDE en question faire le travail.
Mille fois oui. Mais comme je le dis plus haut, avec des sources normalisées, ça devrait sans doute être plus facile.
Entièrement d'accord. J'ajouterais même, une intégration avec le système installé (histoire de ne pas télécharger un truc déjà installé localement via un paquet par exemple).
[^] # Re: Un projet n'est pas que du C++
Posté par rewind (Mastodon) . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 2.
Qu'est-ce que tu entends par là ?
Ça oui. Il y a quelques cas connus à gérer obligatoirement. Je pense à moc, mais aussi à flex/bison.
Ça, ce n'est pas forcément facile, parce que souvent, la méthode de génération est propre à un outil. Mais pareil, quelques cas particuliers devraient être gérés, comme Doxygen.
La normalisation des sources devrait permettre d'améliorer l'automatisation de création de paquet, à mon avis.
[^] # Re: De l'openwashing
Posté par rewind (Mastodon) . En réponse au journal Windows éventuellement en open source?. Évalué à 10.
Pour le coup, je vais me mettre en mode Zenitram pour répondre à Zenitram : «tu as payé quelqu'un pour le faire ? Non, tu veux du gratuit mais tu ne veux pas payer pour ça, et tu te plains alors que personne ne te doit rien.» Je l'ai bien fait, ça va ?