pulkomandy a écrit 1728 commentaires

Dans ce cas précis, on fait la liaison avec le nom de l'option, dès fois qu'il vienne l'idée de mettre une espace entre le - et l'option.

Pourquoi tu crois que ST Microelectronics est toujours vivant et présent en Europe?

Je ne suis pas certain que personne ne s'en soucie…

C'est rigolo 3 minutes mais pas terrible pour communiquer. J'aurais préféré un site plus classique, avec quelques images des années précédentes, ce genre de choses.

Je dirais bien d'aller voir du côté de Jam (la version de Perforce, celle de Boost, celle de Freetype ou celle de Haiku), si c'était pas un outil non maintenu avec 3 forks incompatible… C'est dommage, parce que c'est un bon remplacement de make, avec la possibilité de définir des règles génériques, qui conviendrait pas mal pour ce genre d'usage.

Alors je dois prendre la défense de CMake sur ce point: il y a bien une méthode standard pour la prise en charge des dossiers d'installation, c'est GNUInstallDirs. Le problème, c'est que c'est un ajout relativement récent (ça fait quelques années quand même) et que beaucoup de projets ne l'utilisent pas et codent tout en dur. Et quand c'est utilisé, ça marche tout aussi bien que les autotools (et je dis ça en ayant packagé pas mal de choses pour Haiku, qui fait des trucs bien plus tordus que slackware en terme de chemin standardisés pour les bibliothèques, les manpages, …)

Donc ce n'est pas vraiment la faute de l'outil, mais plutôt d'une mauvaise utilisation (bon et aussi du fait que les dévs de CMake ont pendant quelques temps "oublié" de documenter GNUInstallDirs…

Il y a aussi toute la gestion du packaging (avec CPack) qui de mon expérience, fonctionne plutôt bien, pour générer des tarballs. Et il y a le support de la compilation croisée.

gcc sait le faire, avec la famille d'options qui commencent par -M. Je crois qu'il peut même te générer un Makefile.

C'est ce que cmake utilise pour gérer les dépendances, par exemple.

La vraie raison c'est qu'il y a des distributions Linux qui vont gérer la compilation et le packaging. Donc peu de projets ont besoin de le faire d'eux-même.

Non mais RMS plus personne en a grand chose à faire de ce qu'il raconte. Il y a plein d'autres organisations que la FSF qui font la promotion du libre plus efficacement et de façon pertinente. Va voir la SFC ou la FSFE par exemple.

Je vois les choses d'une façon un peu plus positive: le logiciel libre progresse plus vite que les notions d'éthique qui y étaient souvent associées. ça ne veut pas dire que la partie éthique régresse, au contraire.

Je précise que la communauté cmake (et son canal IRC) est pas mal réactive et disponible pour faire les modifications quand c'est nécessaire. Si tu n'es pas forcé de supporter de vieilles versions de cmake, tu pourras donc obtenir de l'aide pour régler ces problèmes, et s'il y a lieu, ce sera intégré dans cmake directement.

Je mentionne aussi au passage le très pratique cpack, qui permet de générer un .deb, un .rpm et/ou un installeur windows sans trop s'embêter. Mais peut être pas encore les .apk (ce n'est pas trop compliqué d'ajouter le support d'un nouveau format de distribution à cpack, cela dit…)

Je plussoie complètement l'utilisation de ninja. Juste pour le plaisir de le lancer une deuxième fois quand le build est fini et de le voir dire tout de suite "nothing to do". Sur un projet comme WebKit, make dans la même situation mets chez moi presque une minute pour arriver à la même conclusion.

Autres avantages:
- Pas besoin de choisir un -j à la main comme avec make, ninja surveille le system load et s'ajuste tout seul (en tenant compte de la charge CPU effective, donc il lancera plus de jobs en parallèle si la compilation est limitée par les accès disques, et moins si elle est limitée par le CPU ou si on fait autre chose sur la machine pendant ce temps).
- Affichage correct de la sortie de la compilation, sans mélanger la sortie de différent threads
- Affichage du nombre de cibles à compiler, ce qui permet de savoir où on en est dans le build du projet

Ma code review préférée:

Ton script pour enlever les commentaires ne marche pas bien, il en reste un peu!

Tu peux expliquer dans ce cas, quel est l'intérêt de faire du libre si on ne veut rien gérer? J'ai un peu de mal à voir ce que ça peut apporter dans ce cas?

Certes. Tu peux faire un "lancer de code" avec une licence sur Github et on en parle plus. Mais dans ce cas il ne faut pas s'attendre à avoir automagiquement des retours positifs et plein de gens qui contribuent. Je suis d'accord, c'est quand même du libre on a rien à reprocher et c'est déjà très bien.

Mais si on veut profiter des retours de la communauté, des contributions d'autres gens, etc, il faut s'investir un peu plus que ça. ça n'est pas nécessaire, mais ça peut être une bonne justification pour faire du logiciel libre.

Les bugs ne sont jamais "hyper évidents". Je suis dev, je teste mon code autant que je peux mais j'ai pas un temps infini, et dans la plupart des projets il n'y a pas d'équipe QA. Donc c'est souvent moins léché qu'un truc développé correctement par une entreprise (on essaie d'améliorer ça mais c'est loin d'être facile).

Donc, contribue: plains toi que la doc est moisie, que ça plante dans tous les sens et que ça tient pas la charge. Avec des exemples précis. Y'a des chances que tu tombes sur un dev qui sera content de t'aider à régler les problèmes (c'est la contrepartie de ne pas avoir d'équipe QA ou support: tu as une ligne directe pour discuter avec les devs du projet, alors profites-en).

ça me rappelle les histoires avec XChat qui a voulu faire payer les binaires Windows. Sauf que c'est un logiciel libre et qu'une autre personne (silverex) fournissait déjà gratuitement les dits binaires. ça s'est mal fini et ça a forké, et maintenant tout le monde utilise hexchat à la place.

Ce modèle ne me semble pas être le plus malin. Je me dirigerais plus volontiers vers la vente de support, et éventuellement le financement du développement de nouvelles fonctionnalités. Faire payer le travail des devs plutôt que le produit fini, donc.

Si, mettre du code sous licence libre a un coût. Tu ne peux pas le nier sinon ça va jamais marcher en entreprise. Par contre, tu peux le justifier et le "vendre": expliquer les bénéfices (en termes d'image, de contributions externes, etc) et montrer que finalement, le coût initial n'est pas si important que ça en regard.

Mais si tu essaies de faire du libre sans investir sérieusement dedans, ça ne marchera pas. Et le décideur pressé va retenir ça: "le libre, ça marche pas on a essayé". Ne gâche pas ta chance et fait les choses proprement dès le début, merci :)

ça va te coûter plus cher de maintenir ton code, qu'à quelqu'un d'autre de faire un fork et de passer un peu de temps à le nettoyer. Et en plus le fork sera 10 fois moins lourd, aura moins de bugs, etc.

Je ne vois pas comment cette recette peut être gagnante.

« ce n'est pas la politique de la compagnie »

On dit pas compagnie en Français. On dit entreprise. Merci.

On a aussi l'inverse, des gens qui disent "je publierai mon code quand il sera propre et fini". Et ça n'arrive souvent jamais.

Donc oui, merci aux gens qui publient leur code, même sale, même chiant à compiler, même pas fini, même si c'est un truc qui n'a pas servi depuis 15 ans (coucou Autodesk Animator). C'est toujours mieux que de repartir de rien.

ça semble normal pour n'importe quel projet, hein. Si tu ne fais pas ça, un contributeur de ton projet peut venir 15 ans après et dire "hey j'ai changé d'avis, vous pouvez plus utiliser mon code". Ou si tu décides un jour de changer la licence pour les versions futures, tu dois contacter tous les contributeurs un par un pour demander s'ils sont d'accord. Ce qui est un gros bazar sur un projet comme OpenOffice, ou tu vas probablement te retrouver avec des adresses mail qui marchent plus, etc.

Donc la solution, c'est de faire signer un CLA, ou chaque contributeur dit "ok, si vous voulez changer la licence dans le futur, je dis tout de suite que je suis d'accord". ça semble être la moindre des précautions à prendre pour que la chose reste gérable.

D'autres cas:
* Le projet utilise du code GPL et est donc obligé de fournir toutes ses sources à ses clients, mais sans avoir envie que les gens se les approprient,
* Un développeur a bien envie de publier le code, mais sans avoir forcément le temps de le faire correctement,
* Un développeur a senti le vent tourner, et décide de publier les sources de son projet avant qu'il soit annulé et que tout parte à la poubelle (ça s'est produit par exemple pour Tracker, l'explorateur de fichiers de BeOS)

Parfois plus simplement, des gens ont entendu parler du logiciel libre et se disent "trop bien, on a juste à publier nos sources sur un serveur FTP et plein de gens vont venir travailler gratuitement pour nous" ou un truc de ce genre. Parfis au départ il y a quelqu'un qui a essayé de vendre le logiciel libre à son boss, mais le message n'est pas complètement passé…

De façon générale ça peut être plein de sortes de malentendus de ce genre qui aboutissent à un compromis bizarre. Sans forcément de mauvaises intentions pour autant.

Le compromis est simple: pour du libre, tu ne paies rien pour avoir le logiciel au départ. Si tu veux de la maintenance il faut passer à la caisse. Par contre, tu choisis qui tu veux pour le faire.

Avec du logiciel non libre, tu paies éventuellement pour avoir le droit d'utiliser le logiciel, et en plus si tu veux de la maintenance, tu es obligé de l'acheter au même endroit (et souvent c'est vendu ensemble).

Il faut aller voir les conférences de Stallman pour comprendre ça. Pour lui, le modèle viable c'est que tu vas payer un développeur ou une équipe pour leur faire faire des évolutions sur le code, pas pour leur acheter un produit. Tu vas donc être vraiment dans une économie de service.

Alors oui, une conséquence est qu'un chinois/grosse entreprise/… va pouvoir fabriquer des calculatrices moins cher et prendre le code de NumWorks sans contrepartie. Mais par contre, si tu trouves un bug ou si tu as besoin d'une nouvelle fonctionnalité, il ne pourra pas forcément faire grand chose pour toi car il n'aura pas la maîtrise du code.

C'est pour ça aussi que pour que ça marche, il ne devrait pas y avoir de vente liée entre le logiciel et le matériel: tu achètes ton matériel où tu veux. Et tu prends un OS déjà réalisé, ou si tu as des besoins spécifiques, tu paies un dev pour qu'il t'ajoute les morceaux qui manquent. Et tu as tout intérêt à aller voir NumWorks à ce moment là: ils connaissent le code du projet par coeur, donc en principe ils pourront te faire ta nouvelle fonction plus vite et moins cher que n'importe qui d'autre.

C'est un gros changement de modèle économique parce qu'on ne peut plus se dire "on va faire un gros développement pendant 3 ans, mais après on va vendre plein de produits et récupérer notre investissement". Du coup dans ce genre de cas on va plutôt se retrouver avec du crowdfunding, ou les gens vont devoir payer d'avance, et ou ceux qui attendent sans payer pourront bénéficier gratuitement du logiciel produit à la fin, de toutes façons. Du coup le financement va reposer uniquement sur les gens qui ont un besoin urgent et qui sont prêts à payer pour, plutôt que d'attendre que quelqu'un d'autre le fasse à leur place.

Tu l'as lu le contrat utilisateur qui est affiché au premier démarrage avant que tu puisses faire quoi que ce soit? Parce que c'est à peu près certain que tout ça était écrit clairement dedans. Et me répond pas "oui mais le texte est trop long": justement, c'est le premier truc qui doit te mettre la puce à l'oreille, ils ont un tas de choses à te faire accepter.

Alors si tu l'as pas lu, vient pas râler qu'on t'as pas prévenu et que c'était fait dans ton dos.

Ou alors on arrête d'utiliser le flow "merge requests" de Github. Par exemple, en utilisant le flow de Gerrit, qui marche vraiment pas mal et ne nécessite pas la notion de "forks" sur une même instance de l'hébergement.