Même tard, merci pour la réponse. Je ne crois pas qu'on puisse se faire prévenir par email sur linuxfr (et franchement dans les cas où un de nos commentaires innocents déclenchent des discussions déchaînées par certains des trolls sévissant ici, franchement non merci!).
Par contre on peut peut-être continuer la discussion par email. :-)
Tu peux réessayer maintenant, il est tout à fait probable que ça fonctionne.
Ok je réessaierai et je t'enverrai un email directement, avec les messages d'erreur, si ça foire. :-)
autotools/mingw, avec des scripts perso.
C'est peut-être le problème. Je cross-compile sans rien ajouter en "script perso". Normalement un projet devrait bien cross-compiler de la même manière que la compilation native, avec les autotools (on ajoute simplement les options qui vont bien. Je réalise que tes scripts persos, c'est peut-être juste ça: des scripts pour rajouter les options qui vont bien au ./configure et mettre à jour les variables d'environnement. Pour ça j'ai développé mon outil générique en fait: crossroad).
J'arrive parfaitement à cross-compiler la branche gtk-2-24 par exemple sans rien faire spécial (pas tout à fait vrai, j'ai un petit patch en attente, mais une fois ce patch appliqué, c'est bon).
Bon en tous cas, je réessaye pour master, et je te tiens au courant.
Merci pour la réponse.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Si je comprends bien, tu es celui qui maintient ces paquets. J'ai voulu cross-compiler gtk+ master à l'instant, et ça foire. Quand je regarde les Makefile.am, je constate que c'est normal car il y a des règles vraisemblablement manquantes requises par d'autres règles conditionnelles entourées de "if OS_WIN32" (donc ça reste invisible jusqu'à ce qu'on compiles pour Win).
Donc la question que je me pose est: tu compiles avec les autotools ou avec un autre système de build (je vois des makefile.msc qui parle de compiler avec Microsoft C apparemment et je vois des fichiers pour Visual Studio)?
Autre question: tu compiles sous Windows, ou tu cross-compiles?
Merci!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ahahah. Tu aimes bien dialoguer et argumenter tout seul, même lorsqu'on te dit qu'on est d'accord avec toi.
Et oui j'ai été un peu fort dans mon propos, ce que je n'aime pas faire. Mais c'est vraiment parce que c'est toi. :-D Tu aimes tellement troller juste pour troller que j'ai même plus envie de répondre à tes messages. D'ailleurs c'est ma dernière réponse sur le sujet. Comme j'ai dit, je suis d'accord. À toi de pas me croire et de savoir mieux que moi ce que je pense, si ça t'amuse. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bref, ffmpeg s'occupe d'être rétro-compatible […] et d'être compatible avec libav.
Juste au cas donc où j'étais pas assez clair, le bug que j'avais patché était justement qu'a priori le code marchait avec le libav du projet libav, mais pas le libav de ffmpeg que j'avais sur ma machine. Donc ffmpeg n'était pas compatible avec "l'autre" libav.
Note encore une fois: je ne dis pas que c'est de leur faute, et je suis aussi neutre que possible. Je ne prends pas trop parti. C'est juste une constatation et en tant qu'utilisateur, ben on se retrouve avec des bugs, et dire que le libav de ffmpeg est "compatible avec libav" — juste parce que c'est écrit — n'est pas toujours vrai (même si probablement ils essaient, j'ai pas vérifié, mais c'est apparemment ce qui ressort des dires de gens comme toi, et je veux bien vous croire).
C'est pourquoi je dis que la solution n'est pas tenable, et même en choisissant libav comme base en se disant que ça marchera partout (en partant du principe que ffmpeg se dit compatible avec libav), ben on se retrouve avec des bugs. C'est chiant et intenable comme situation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne parlais pas de différence, mais de compatibilité au niveau des arguments en ligne de commande, voire de l'API (pouvoir remplacer ffmpeg par libav et inversement sans que ton script/programme se retrouve cassé. Ce qui compte quand on remplace ffmpeg par libav dans une distrib')
J'avais bien compris, et je dis justement que c'est pas suffisant. L'API peut être similaire, mais avec les mêmes arguments justement, un programme se retrouvera cassé selon l'implémentation. C'est le cas dans le bug que j'ai corrigé sur blender où on se retrouvait avec diverses implémentations d'un même codec selon le projet (à l'époque où j'ai patché, j'utilisais l'implémentation libav de ffmpeg!), et on doit tester à l'exécution. Avec les mêmes arguments justement, c'était pas portable de l'un à l'autre, ni réciproquement.
Morceaux choisis :
Je donnais des cas réels avec patchs à l'appui. Pas des "morceaux choisis" extraits de doc ou de beaux discours.
Maintenant soyons clair. Je ne dis pas que l'un est mieux que l'autre et je ne jette sûrement pas la pierre à l'équipe de ffmpeg sur le coup. Vu de l'extérieur (de loin, car je ne suis pas vraiment cette histoire, en gros les commentaires dans ton genre ou les blog posts dont les liens sont donnés plus haut sont informatifs pour moi), il semblerait que l'équipe de ffmpeg a en effet un comportement plus sain que ceux de libav, ou du moins font plus d'efforts. Peut-être que le problème que j'avais patché à l'époque n'était qu'une erreur passagère, un oubli, et que depuis l'équipe de ffmpeg a amélioré la compatibilité des codecs avec libav.
Néanmoins je dis juste que tout n'est pas aussi bien et bon avec l'implémentation de ffmpeg qu'ils le prétendent. Probablement pas de leur faute s'ils doivent constamment faire avec une équipe hostile chez libav, mais c'est un fait, appuyé par des patchs ici et là de divers dév, et des logiciels qui cassent, etc.
Pour moi, c'est une situation qui ne peut pas tenir. C'est pas sain. On ne peut pas avoir deux équipes hostiles dont l'une refuse catégoriquement de collaborer avec l'autre, et qui travaillent sur une API de même nom. Même si la première fait énormément d'efforts dans ce sens, les efforts doivent être dans les 2 sens, sinon ça ne peut être que bancal!
Il faut que l'une accepte de renommer ou alors que les deux équipes se mettent finalement d'accord pour collaborer. Et je suis d'accord que ce serait bien plus justifié si le fork (donc le projet libav) était celui qui renomme, car après tout… ben ils sont un fork du premier! Mais de manière évidente (ne serait-ce que par le nom de projet qu'ils ont choisi: libav), il semblerait qu'ils ne veulent vraiment pas et qu'ils sont bornés. Donc je vois pas de solution, mais tout ce que je constate, c'est que la situation est devenue un véritable enfer pour les utilisateurs comme pour les développeurs tiers. Et ce, quelque soit la bonne volonté de l'équipe ffmpeg. Là n'est pas la question.
Les faits sont dans les patchs et les commits des projets, dans les tentatives de compilation, et dans les logiciels qui cassent à l'usage (même en utilisant ffmpeg!), pas dans des "morceaux choisis" sur des sites web.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je sais pas vraiment ce que signifie "l'inverse n'est pas vrai" (j'entends par là: "ça veut rien dire" car si A fait différent de B, alors B est différent de A). Il s'agit "soi-disant" de deux implémentations de libav, et elles sont différentes. Donc c'est juste pénible. J'ai déjà dû corriger un problème avec des patchs dans deux softwares que j'utilise à cause de différences entre les implémentations: blender et DVDStyler. Et c'est des bugs plus subtils que juste une API différente (en gros, des implémentations différentes de même codecs), donc plus difficiles à repérer et corriger (détection à l'exécution), comme on peut le voir dans mes patchs, ce qui fait que ces bugs ont été présents un moment dans la nature et sont probablement encore présents dans divers logiciels.
Aussi j'ai régulièrement des problèmes avec mplayer depuis que je suis passé sous Mint alors que c'était mon logiciel vidéo phare. A priori c'est parce que les paquetages utilisés sont ceux de libav (alors que les dév mplayer utilisent bien sûr la version de ffmpeg).
Et lorsque j'essaie de compiler certains software qui utilisent libav, j'ai régulièrement des problèmes, selon que les dévs utilisent plutôt une version, et moi une autre.
Franchement c'est juste ridicule. C'est une guerre de gamins. La solution est pourtant simple: s'ils veulent réellement faire différent, très bien! Aucun problème pour moi. Mais renommez. Que l'une des équipes trouve un nouveau nom et on peut installer les deux libs côte-à-côte, et ainsi les divers logiciels choisissent la librairie de leur rêve et les blems sont finis. Je comprends bien que le nom est important pour la notoriété et la base utilisateur, mais c'est pas notre problème! Ils ont fait un choix conscient de forker, ils pourraient assumer jusqu'au bout.
Parce que là en tant que simple utilisateur, on se retrouve pris en sandwich/otage dans une guerre absurde où on nous demande de choisir aussi en gros, sauf qu'en vrai, on nous laisse pas le choix (c'est en général notre distrib qui choisit), et on se retrouve avec des blems sur une moitié des logiciels qui utilisent libav.
Et en tant que dév tier neutre, c'est aussi chiant, car on doit constamment corriger des bugs et des changements pour essayer non plus de suivre 1 librairie, mais pour contourner les différences qui apparaissent progressivement entre 2 librairies qui prétendent être la même sans l'être.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est toujours base sur le X11 de mascosx ou ils ont finit par utiliser cocoa?
Entre x11 et les raccourcis mappes sur ctrl plutot que cmd, c'etait vraiment une plaie a utiliser.
Pour GIMP, on conseille aux gens d'utiliser le backend Quartz de GTK+ pour OSX (= Cocoa d'après ce que je lis sur le web), car GTK+ sous OSX avec X11 serait vraiment trop mauvais/cassé.
Donc la réponse est "oui, GTK+ marche avec Cocoa", et c'est même conseillé (en tous cas par l'équipe GIMP). Cependant il semblerait que les "ports" (des sortes de paquetages pour OSX, si je pige bien) fournissent plus souvent un GTK+ compilé pour X11. L'autre jour, le designer principal de l'équipe réinstallait GIMP et il a dû compiler GTK+ à la main avec la cible "quartz" (option --with-gdktarget=[x11/win32/quartz/directfb]) à cause de cela.
Tout cela avec beaucoup d'incertitudes dans mes propos, car je n'ai moi-même accès à aucun Mac, donc je ne sais pas à quel point le port Quartz est bien ou non. Et a priori il a aussi pas mal de bugs. Mais il reste mieux que sous X11 pour OSX d'après ce que disent ceux qui utilisent GIMP sous OSX (du moins pour GTK+ 2, car GIMP n'a pas encore migré vers GTK+ 3).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pas forcément. Parfois une simple discussion et une entrevue avec des ayant-droits vous permettent d'avoir des droits pour faire ce que vous voulez avec l'oeuvre et les dérivés
Sur les exemples cités plus haut? Genre tu crois vraiment que Disney va autoriser quelqu'un à faire un roman sur Mickey à l'œil? Sans demander sa part ou demander à relire et corriger l'œuvre avant publication? Soyons sérieux. Ça peut marcher dans des cas très rares, mais c'est du cas par cas. Dans la majorité des cas, l'auteur originel va essayer de vampiriser le second auteur, ou bien simplement refuser.
Et dans tous les cas, ça n'est pas de l'art. On transforme un processus artistique fluide en négociation business compliquée. J'appellerai pas ça un processus "sain".
(et je sais de quoi je parle :-)
Ça, c'est juste de la rhétorique peu subtile. Genre "je suis un connaisseur, j'ai vécu!" pour appuyer tes dires, mais sans donner des détails. Je suis sûr que ça a un nom en rhétorique!
On critique assez bien les studios US qui font des copies et remake d'oeuvres passées, pourquoi vouloir les singer ? Pourquoi vouloir copier les autres ?
Tu devrais vraiment lire les 2 œuvres que je cite (par exemple) avant de parler de juste "copier" les autres, ou de comparer avec les remakes d'Hollywood. Et encore y en a plein d'autres des bonnes œuvres dérivées de divers œuvres, mais ces deux là sont parmi mes préférées. Des chef-d'œuvres.
Pourquoi ne pas innover et créer de nouveaux héros ? […] Après, il existe de bons exemples dans des remakes/reboots d'oeuvres, je pense notamment aux Comics US qui se renouvellent parfois bien
C'est peut-être là le problème: tu sembles croire que l'inspiration d'œuvre n'est pas de l'innovation ni de la création. Franchement c'est l'histoire de l'art. Les artistes se sont constamment inspirés et copiés les uns des autres. Par exemple quelqu'un citait Mona Lisa. C'est en effet un des exemples les plus copiés. Il existe même une copie qui a été faite… en même temps que l'original, dans le même studio par un étudiant de Da Vinci (c'est du moins ce que pensent les historiens d'art)!
Cette réplique est visible au Musée Del Prado (Madrid). Tu vas aller leur dire que c'est pas de l'art? Pourquoi il a pas innové et utilisé son propre modèle au lieu de copier?
Et en même temps, tu sembles dire que les comics US sont un bon contre-exemple de gens qui y arrivent parfois. Alors que je trouve au contraire que c'est justement l'exemple de ce qu'il faut pas faire. Ces remakes arrêtent pas de raconter plus ou moins la même histoire, encore et encore. On l'aura compris que les parents de l'un sont morts, ou que cet autre aura été mordu par une araignée! Comment arrives-tu à dire que celui qui raconte complètement une nouvelle histoire (dans les deux œuvres que je cite) en partant de personnages très charismatiques que l'auteur se ré-approprie totalement est de la copie qui "singe" les autres, alors que le même qui raconte pour la 10ème fois l'histoire sans intérêt d'un mec avec des pouvoirs (car c'est là l'intérêt en vrai: on lui fait faire des cabrioles, et il a "même pas mal"!), c'est un bon renouvellement?
Bon je dis pas qu'on peut pas aussi raconter une même histoire en se la ré-appropriant et ce serait aussi une approche artistique. J'essaie juste de te mettre en face de tes contradictions. :p
Tout comme l'étudiant de Da Vinci a ré-interprété Mona Lisa au lieu de se contenter d'essayer de faire un identique.
Ceci dit franchement, citer les comics US comme bon exemple de copie, c'est fort.
Néanmoins je pense qu'on a simplement des valeurs très différentes sur la notion d'art. Mais comme tu dis: "goûts et couleurs".
Dans tous les cas, je vais arrêter là, car je sens que tu ne seras pas d'accord de toutes façons, et j'aime pas faire tourner en boucle les argumentaires. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En fait, ma principale interrogation serait : mais pourquoi les gens veulent absolument que cela tombe dans le domaine public ? Non que je n'y vois d'objection, j'aimerais cependant connaitre les raisons profondes de leurs engagements.
Parce que comme tu dis:
"Les goûts et les couleurs"
Et donc peut-être que des gens aiment le concept de Mickey ou de Tintin, mais pas forcément ce qui sort actuellement, et qu'ils aimeraient pouvoir écrire et vendre leurs propres aventures de Mickey, Tintin, etc. sans demander l'aval (qu'ils n'obtiendront probablement pas, à moins de poser la grosse mallette de billet et d'accepter un droit de regard et de changement sur leur œuvre) de Disney ou autre gestionnaire ayant-droit.
Je pense que j'ai donné 2 très bons exemples plus haut d'œuvres qui n'ont rien à envier aux originaux, mais qui n'auraient probablement pas pu exister s'ils avaient dû demander l'autorisation à une grosse multinationale qui n'a rien à faire d'auteurs indépendants.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je sais pas quelle serait la méthode propre, mais perso je m'embêterai pas: un bon vieux script qui appelle le bon programme avec les bons arguments, et voila.
Oui. Mais c'est vrai que c'est dommage que chaque desktop y va de son propre système. Comme Yves, j'avais essayé de configurer le navigateur de fichiers de plein de façons (parce qu'en cherchant des infos sur le web, chaque bureau y allait de sa méthode et même les logiciels XDG, au lieu de la jouer "on impose une logique commune", ils essaient de détecter ton bureau et d'utiliser en priorité les méthodes non standardisée), sans succès. Au final, ça rend des choses simples super compliquées et surtout contradictoires (puisqu'on croit configurer quelque chose, mais on obtient quelque chose de différent). Ce sont des petits détails qui compliquent la vie.
D'ailleurs même ceux qui utilisent des desktop managers, je suis sûr que des fois ils sont perdus. Déjà s'ils ont plusieurs desktops installés. Même sans le vouloir, avec les dépendances de fous de certaines apps, si l'utilisateur fait pas gaffe, il se met à installer un autre desktop. Ensuite il verra plein de progs d'administration "dupliqués" dans son menu, qui ont l'air de faire la même chose. Sans compter les logiciels d'administration de la distrib, qui se retrouvent à faire pareil aussi qu'un logiciel KDE/GNOME/XFCE. Franchement je suis souvent perdu moi-même.
Quand je cherche des applications stand-alone, perso je regarde plus du côté de LXDE que des autres DE. Ils ont tendance à tirer nettement moins de dépendances…
Je regarderai ce que fait le daemon XFCE peut-être. gnome-settings-daemon fait au moins 2 choses que je recherchais: déjà comme dit plus haut, j'ai des icônes (je m'en fiche un peu desquelles, tant que j'ai pas des icônes cassées); et aussi il charge mon profil de couleur ICC.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
1) Dans les applets qui ouvrent un gestionnaire de fichier, ça s'obstine à lancer Nautilus
Chez moi, ça lance Nemo. J'essaierai la méthode que tu cites dans un message plus bas, sauf que le web me dit que ce serait ~/.local/share/applications/mimeapps.list plutôt que defaults.list? Enfin je verrai.
Mais surtout ce qui me paraît problématique est que ces fichiers semblent davantage fait pour spécifier des .desktop, pas notre propre commande. Déjà ça veut dire qu'on peut pas aisément utiliser un prog sans .desktop (certes, ça devient rare), mais même utiliser un prog qui a un .desktop mais avec des options particulières.
Par exemple, nemo me convient bien à une chose près: il lance aussi un desktop manager par défaut. Or je veux pas de bureau (je lance openbox simple). Je voudrais donc que cairo-dock me lance nemo --no-desktop. Mais comment faire cela en donnant un fichier .desktop? Dois-je créer mon propre .desktop?
Aussi n'existe-t-il pas un logiciel de configuration "générique" (= non lié à un desktop en particulier, pour configurer des choses communes, comme ces préfs XDG)?
Voilà, c'est tout. Enfin, il me manque aussi toutes les icônes dans Nautilus
En fait tu dois configurer le thème de ton bureau toi-même. Comme toi au début, je n'avais pas d'icône dans divers programmes, ni même dans le menu d'application et divers plugins de cairo-dock. J'ai contourné ce problème avec gnome-settings-daemon & dans mon autostart. Ça ne lance pas un desktop GNOME complet, mais la partie qu'il me fallait. Pas sûr que ça lance pas aussi quelques trucs dont je veux pas, par contre. KDE ou XFCE auront leur propre daemon équivalent. A priori, tu dois être capable de configurer ces trucs toi-même en lisant http://www.freedesktop.org/wiki/Specifications/xsettings-spec/. Mais je t'avoue que je suis pas allé lire cela moi-même. Ma solution actuelle me convient.
J'ai créé un rapport de bug chez cairo-dock sur ce sujet précis y a quelques semaines. Et ce fut globalement le résultat.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Étant donné que le cœur de GIMP est désormais poussé vers GEGL, cela signifie que GIMP est de plus en plus seulement une UI. Presque tout ce qui concerne le traitement d'image passe dans GEGL. GIMP, c'est donc principalement du code GTK+ lié à du code GEGL (un widget GTK+ appelle telle opération GEGL).
Donc passer en QT n'a pas trop de sens, car ça signifierait en gros tuer 90% du code, je pense. QIMP ne serait donc pas un port de GIMP, mais pourrait tout à fait être une nouvelle application QT faite à partir de zéro, qui utiliserait aussi GEGL (ce qui est fortement encouragé! Plus il y aura d'applications utilisant cette lib commune de traitement d'images, plus celle-ci sera améliorée, avec de nouvelles opérations, plus performante, etc.).
Ceci dit, cela resterait un énorme boulot. Dans un logiciel comme GIMP, l'UI reste très importante. Des logiciels Libres de traitement d'image qui font des trucs de ouf, y en a d'autres, comme ImageMagick, mais beaucoup de gens veulent une UI. Donc ils utilisent GIMP, alors peut-être même que le rendu final d'ImageMagick aurait peut-être plus été ce qu'ils voulaient, ou bien que cela aurait été plus facile pour traiter des lots d'images s'ils avaient pris juste 5 min à lire la doc. Si je me plante pas G'mic aussi a une UI en ligne de commande, mais les gens l'utilisent surtout à travers GIMP (ce qui n'ajoute absolument rien à G'Mic quand seulement ces effets G'mic sont appliqués à l'image). L'UI de GIMP a beaucoup de problèmes et mérite vraiment d'être améliorée radicalement, voire transformée complètement. Mais elle a le mérite d'exister. Toute nouvelle implémentation d'UI (en QT par ex), même s'ils n'auront pas à se préoccuper autant du cœur du programme (en se basant aussi sur GEGL), prendra tout de même énormément de temps et de dédication pour en arriver au même nombre de fonctionnalités que GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Sinon, pendant que j'y pense, si tu as une batterie de tests, je peux toujours voir ce que ça donne sur mes systèmes… Me connaissant, je ne serai pas surpris qu'il manque des dépendances dans ta description ( système lourdement allégé, si je suis puis dire )
Batterie de tests pour vérifier des trucs génériques sur des logiciels à cross-compiler ou pour crossroad même?
Si c'est des tests génériques pour des logiciels, non je fournis pas ça avec crossroad. Il ne s'agit que d'un système de compilation, pas un environnement de test.
Si tu parles de tests pour vérifier que crossroad marche, ben le plus simple, c'est de l'installer et l'essayer. J'ai vraiment tout fait pour que ce soit extrêmement facile à installer (avec pip3 notamment, sinon un simple ./setup.py très standard) et utiliser (commandes courtes, faciles à se remémorer, et similaire à une compilation pour le système natif). S'il te manque une dépendance que j'ai pas vue, donc pas citée, tu auras une erreur, et tu pourras me la remonter. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
la justification est d'éviter que n'importe qui fasse n'importe quoi du personnage Tintin
Franchement c'est comme laisser les ayant-droits décider quoi faire. Ils peuvent faire de la merde (c'est en général le cas), ou des trucs biens (c'est rare. Pour tout dire, j'ai pas trop d'exemple en tête de ce cas!). Pourquoi ces gens seraient-ils plus à même de décider ce qui "préserve" l'œuvre? Par définition, ils ne sont pas les auteurs originels. Donc quoi qu'ils fassent, ils préserveront pas l'œuvre. En fait on ne peut pas "préserver" une œuvre qui n'est pas notre. On peut uniquement "la faire notre". Donc la modifier, la faire évoluer, la transcender. C'est ça l'art. C'est pas essayer de "copier" (souvent en aseptisant, en enlevant des parties "qui plaisent pas", v'là pour la préservation). Tant que ces "ayant-droits" n'auront pas compris ça, ils ne feront jamais rien de bien avec les œuvres dont ils ont les droits. En gros ils agissent plus comme des hommes de loi que comme des artistes (d'ailleurs ils ne se présentent pas comme des "artistes", mais comme des "gestionnaires", ça montre l'ambiance).
Pour tout dire, le fait qu'ils aient exclusivité les pousse même davantage à faire de la merde que du bon, puisque par définition, il n'y a pas concurrence, donc pourquoi se fouler quand on peut faire de l'argent facile? Tu parles de figurine/pub/jouet comme mauvaise utilisation par ex. Ben justement j'ai un peu l'impression que c'est ça ce qu'ils font, pour la plupart des œuvres "gérés" par des ayant-droits. Ou alors des films 3D pour suivre la mode, ou un énième remake nul avec un scénar bidon (mix de plusieurs scénarios et on dit que c'est une nouvelle histoire), et des acteurs célèbres payés à prix d'or.
Au contraire, regarde toutes les œuvres du domaine public. Y a foultitude de dérivés, la concurrence est rude, et y a en effet énormément de trucs peu inspirés (mais ça veut pas dire pour autant que c'était voulu: au moins les auteurs ont essayés. C'est mieux que de faire un truc bidon par le service marketing juste parce qu'on a exclu. Donc je respecte tout de même bien plus leur travail). Mais y a aussi des perles incroyables.
Vois "_Peter Pan_", de Sire Matthew Barry. Un des contes les plus repris dans le monde, partout (même par Disney qui a totalement massacré l'œuvre). Beaucoup de trucs bidons. Mais dans le lot, y a au moins une véritable œuvre d'art qui a non seulement gardé beaucoup de l'esprit (tout le côté un peu torturé de Peter Pan, avec la fée vraiment malsaine, le fait que les enfants imaginaires sont peut-être pas si heureux que ça, le côté "rester enfant à jamais" pas si bon-enfant justement, car les enfants sont très cruels, le pays imaginaire lui-même pas aussi bien qu'il apparaît au début, notamment la tristesse d'oublier tout, même les bons moments, etc.), tout en renouvelant complètement avec l'histoire de la création de Peter Pan, au lieu de faire un énième remake massacré: "_Peter Pan_" de Loisel. Cette BD est un chef d'œuvre.
Quant à "_l'Île au Trésor_", de Stevenson, lui aussi repris à toutes les sauces et sous de nombreuses formes. J'ai lu un des meilleurs romans que j'ai jamais lu il y a quelques années: "_Long John Silver_", de Björn Larsson. C'est le roman autobiographique du pirate Long John Silver. Et c'est extraordinaire. Le roman originel est sympa, c'est à lire, ne serait-ce que parce que c'est un classique. Bon c'est un peu un roman pour enfant, mais ça se lit bien. Mais le "_Long John Silver_" de Larsson transcende l'original (d'après moi. Bien sûr ça reste un avis perso). Et je suis vraiment content que l'originel soit passé dans le domaine public. Sans cela, l'humanité serait passée à côté d'un chef d'œuvre, un vrai bijou de la littérature. C'est vraiment une très bonne évolution d'une œuvre que je qualifierais originellement de juste "agréable à lire pour passer le temps". Encore heureux que personne a cherché à "préserver" une quelconque "forme" qui n'a de toutes façons jamais existée.
Tout ça pour dire que cette raison est mauvaise au mieux, mais surtout bidon.
Je rappelle que vous pouvez trouver les originaux de diverses œuvres du domaine public sur Wikisource et le Projet Gutenberg.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Hors ce que j'aimerai c'est d'avoir un outil qui permet d'installer toutes les libs systems dont j'ai besoin en local, pour ne pa avoir a tout recompiler en static avec par exemple
Mais je pige pas vraiment non plus pourquoi tu penses avoir besoin de recompiler pour des libs statiques. Les paquetages de développement sur les distribs que je connais fournissent aussi les libs statiques. Pas seulement les dynamiques. C'est le cas sur ma Linux Mint (donc Ubuntu aussi). Je suis à peu près sûr que c'était aussi le cas sur ma Mageia. Etc.
Si l auteur du journal arrive a le faire pour windows
L'auteur du journal, c'est moi, au passage.
je dois trimballer mon programme, il est installe sur mon pc avec les lib du pc, je vais en faire une version ou les libs du pc vont etre telechargees et installees dans un repertoire cible pour la compilation de mon projet.
On appelle ça le gestionnaire de paquets sous Linux! :-p Plus sérieusement, je comprends pas trop le problème. J'ai l'impression que tu dis que j'arrive à faire un truc pour Windows avec crossroad qu'on n'a pas pour Linux en temps normal. Mais c'est l'inverse. On a le gestionnaire de paquet pour Linux. Et avec crossroad, je ne fais que reproduire le concept pour Windows. Mais pour Linux, ben ça existe déjà! Rien à reproduire!
Par contre si je dois compiler toutes ces libs alors le makefile va devenir bien plus complexe a gerer.
Es-tu en train de dire que tu écris ton Makefile entièrement à la main? Si c'est le cas, ne cherche plus. Je crois qu'on a trouvé ton problème. Faire un Makefile entièrement à la main n'est plus une option viable pour n'importe quel projet qui dépasse le jouet. Tu fais ça au début pour apprendre ce qu'est un Makefile, mais ensuite pour un vrai projet, avec des dépendances, tu génères ton Makefile avec des outils qui vont tout faire pour toi. Que ce soit les autotools, cmake, qmake, ou quoi que ce soit. On n'écrit pas de code spécifique pour gérer des libs statiques et pourtant les Makefile générés par les autotools/cmake sont capable de générer soit du dynamique, soit du statique, soit les deux à la fois!
Si nous faisions le code avec matlab, il suffirait d'utiliser mcc et on aurait une version portable.
Oulah! Tu parles complètement d'autre chose là. Ça fait des années que j'ai plus touché matlab, mais au dernières nouvelles, il s'agit de code interprété. Tu peux aussi bien écrire du code matlab sur Linux si tu veux, et il sera tout aussi portable. Pareil pour n'importe quel language interprété. Ça n'a rien à voir avec des problèmes de chaîne de compilation, ni avec l'OS ou le fait que c'est proprio ou libre.
C'est tout de meme un vrai probleme de linux par rapport a windows et du libre par rapport au proprio.
Franchement je crois bien que s'il y a un point où on n'a pas à rougir, c'est notre chaîne de compilation et les divers outils de gestion de projets. C'est pas pour rien qu'on cherche à cross-compiler sur Linux pour Windows, même si on a accès à un Windows (en VM par ex pour moi): car c'est 100 fois plus simple sous nux!
Je pense qu'il y a deja eu de nombreux debats avec par exemple Zenitram qui se plaignait de la difficulte de package pour linux
Je ne suis pas la moindre des discussions sur linuxfr, mais je me demandes si tu ne cites pas là un tout autre sujet, qui est celui des gestionnaires de paquetage, pas la chaîne de compilation.
En fait on a fait la betise de ne pas utiliser des libs static des le debut,
Franchement je crois que votre bêtise fut d'écrire apparemment vos Makefile à la main (si j'arrive bien à lire entre tes lignes. Désolé si je me plante). Je vous conseille de passer un peu de temps pour réécrire la chaîne de compilation de votre projet. Lisez des tutos cmake ou autotools, et choisissez l'un des deux (ou un autre, je suis pas sectaire).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
donc de compiler automatiquement le bon code assembleur, que ce soit avec des instructions NEON, SSE, AVX, etc. par contre il faut qu'à la compilation, je lui dise que pour tel environnement (ex : windows sur smartphone) il prenne les instructions NEON, pour d'autres (windows sur pc), il prenne les SSE, etc. quand Je n'ai pas les idées très claires là-dessus mais c'est l'idée…
À la compilation, tu peux pas configurer ce que le binaire fera à l'exécution. La seule chose que tu peux faire, c'est compiler plusieurs versions de ton logiciel, et installer chaque version sur la bonne machine. Chaque binaire aura un code machine différent (soit parce que le code source est différent et sélectionné par des commandes pré-processeur, soit parce que le compilateur va générer un code machine différent pour le même code source).
Si tu veux un seul binaire commun qui fait diverses choses selon l'architecture précises, on revient sur des librairies d'abstraction, comme OpenCL et compagnie avec une logique dans le code. Faut pas que tu mélanges les deux. C'est complémentaire.
Et de manière général, il n'y a pas de magie. Le multi-tâche (threading, multi-proc, etc.), c'est dans le code. Ça peut être plus ou moins encapsulés dans des librairies haut niveau, mais ça reste au dév de créer la logique. Une option du compilateur pour créer du code parallèle à partir de code linéaire, ça n'existe pas.
Donc ce genre de choses n'a vraiment rien à voir avec la compilation (bien sûr y a des options de compilation en rapport avec le multi-thread, mais c'est pas pour transformer magiquement ton code), et donc avec crossroad.
La seule chose qui a un rapport, c'est quand tu parles de générer des sets d'instructions plus précis que juste x86 32/64-bit. Comme dit plus haut, fais un man gcc. Et fais une recherche avec tes mots clés. Je trouve des trucs pour NEON (-mfpu=neon), plein de mentions de SSE (plein d'options, à toi de choisir lesquelles tu veux), pareil pour AVX. Ça oui, tu peux rajouter ces options dans ton CFLAGS (donc probablement aussi fonctionnel avec crossroad).
Et encore même pour ça, ça ne signifie pas que le code final va soudainement être parfaitement optimisé. Le compilateur va tenter de générer des codes spécifiques plus performants s'il détecte des schémas connus. Et pour ça les compilos modernes sont très forts et peuvent être plus performants que la plupart des dévs. Mais une machine reste moins intelligente qu'un humain malin. Et il est donc possible que tu puisses optimiser davantage avec du code assembleur (comme il est aussi possible que tu fasses pire que l'optimisation du compilo).
Pour tout le reste, c'est à toi de bosser et de modifier ton code. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Compiler en static de Linux vers Linux demande de refaire tout le travail de makefile toute la compilation en local de toutes tes bibliotheques
Qu'appelles-tu "refaire tout le travail de makefile"? Entends-tu "modifier" le makefile? Parce que normalement tu ne devrais pas avoir à toucher aux Makefile. Il y a en général une option pour compiler la librairie en statique (--enable-static ou équivalent). Je ne compile jamais en statique, mais je sais que ça devrait être tout aussi simple qu'en dynamique.
Ça te permettrait en effet d'avoir un gros binaire avec tout dedans et ça résoud le problème.
Quand a ton lien sur les les bibliotheaues partagees, c'est justement le probleme … je ne sais pas ce que j'aurai lorsque j'arriverai.
Comme dit plus haut, tu peux tout à fait installer tout dans un préfixe de ton choix. Donc "si", tu sais ce que tu auras quand tu arriveras. :-)
Bien sûr, je ne conseillerais pas normalement ce type de procédure pour une belle install propre, avec des libs partagées par divers programmes, etc. Mais si cela te convient et peut te permettre de contourner l'administration trop procédurière, faire gagner des semaines de boulot à tout le monde, alors pourquoi pas.
En gros tu crées ton préfixe perso. Par exemple $HOME/nomduprojet/ et tu compiles tous tes programmes avec --prefix=$HOME/nomduprojet/
Tu voudras probablement temporairement changer ton $PATH, $ACLOCAL_FLAGS, $PKG_CONFIG_PATH, $LD_LIBRARY_PATH, etc. relativement à ce préfixe, bien sûr.
Au final l'ensemble du projet et toutes les dépendances seront inclus dans ce préfixe. Tu n'auras alors qu'à compresser le répertoire et envoyer tout ce qu'il y a dedans sur ta machine cible. Puis sur ta machine, tu décompresses où tu veux, et tu mets à jour le PATH et le LD_LIBRARY_PATH. En général, il n'est même pas nécessaire d'avoir les mêmes qu'à la compilation. Je dis "en général" car selon le programme, il est possible que le préfixe de compilation se retrouve dans des fichiers de conf, voire même dans des binaires compilés. Donc ça reste du cas par cas, un peu dangereux, et il est quand même préférable de savoir quel sera le préfixe final. Mais juste savoir le préfixe que tu peux utiliser, ça ne doit pas être si dur à savoir, non?
Normalement tes admins devraient savoir tout ça ceci dit! Je comprends pas pourquoi tu te retrouves à faire cela si c'est pas ton boulot. Les admins devraient te dire ce dont ils ont besoin. C'est leur boulot.
je sais que j'aurais un linux 64 bits sans droits d'admin.
Ça c'est vraiment pas un blem. Sauf si ton programme est censé avoir accès à des ressources systèmes interdites aux utilisateurs (parce que ça peut faire tout pêter, ou bien parce que ça peut donner des infos sur les autres utilisateurs, par ex). Dans ce cas, il te faut être root à un moment donné pour au minimum faire un setuid. Mais la plupart des programmes utilisateurs n'ont pas ce cas d'usage et peuvent tout à fait être installés sans le moindre droit par un utilisateur normal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ben je prends tout patch pour le support de qmake dans crossroad. Si tu me le fais, je l'intègre! :-)
Ou alors faudra attendre que je tombe sur un projet qmake que je veuille cross-compiler (mais ça peut prendre très longtemps! J'utilise pas qmake pour mes projets, et je tombe rarement sur des projets qmake).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Même lorsqu'on compile pour sa propre plateforme, on compile très rarement pour une architecture très précise. En gros, ceux qui font cela sont par exemple les gens sous Gentoo, ou bien des fous de l'optimisation. J'imagine aussi que dans le monde des jeux vidéos ultra-performants (c'est juste une hypothèse, je sais pas s'ils font vraiment ça), les dévs vont compiler plusieurs versions pour les processeurs et CG majeurs, et vont embarquer ainsi toutes ces versions alternatives dans leur installeur qui détectera en temps réel et installera une version optimisé si possible (une version plus générique sinon).
Mais à part ça, les développeurs se contentent de fournir deux versions pour x86 (une 32 et une 64-bit), pareil pour Mac, et pour Linux, etc. (ça fait déjà pas mal de versions!)
Et encore certains se contentent de 32-bit en se disant que de toutes façons, tous les OS 64-bit ont un layer de compatibilité 32-bit. Voire même livrent le binaire Win pour Nux en embarquant Wine. On a tous vu ça, n'est-ce pas?
Donc ./configure, même si la cible est ta propre plateforme, va fournir par défaut un binaire générique (c'est à dire un code non optimisé pour le plus petit dénominateur commun similaire à ta machine, par ex "tout processeur x86 32-bit"), et non un binaire optimisé pour ton proc exact. Parce que c'est ce que la plupart des gens veulent. Si tu veux du code spécifique, tu dois spécifier explicitement l'architecture à ton compilateur. Par exemple, fait un man gcc. Regarde des options du type -march, -mcpu, -mtune, déjà. Et encore ça c'est de la petite optimisation. Après chaque architecture a son propre lot d'options spécifiques pour aller plus loin, activer ou non des fonctionnalités, etc. Normalement tu vas activer de telles options en modifiant ton CFLAGS pour C, CXXFLAGS pour C++, etc.
J'en dirais pas plus parce que je suis loin d'être un pro de l'optimisation. Le plus loin que j'ai fait, c'est quand j'utilisais Gentoo, et encore je me contentais de spécifier l'architecture processeur.
En général, je fais plutôt comme tout le monde: je fais simple et compile générique. :-)
Donc est-ce que crossroad peut aussi compiler avec des optimisations? Ben j'ai pas testé, mais étant donné que MinGW-w64 se base sur gcc, je pense que oui. J'imagine qu'il suffit de choisir tes options, faire divers CFLAGS pour les diverses architectures particulières que tu veux, puis faire un export CFLAGS="-some-great-optimization -another" (tu fais un man gcc et tu fais ton marché). Bien sûr, fait ça avant de commencer à configurer (crossroad configure) et compiler pour que ce soit bien pris en compte.
En outre je te conseille fortement d'ajouter tes flags l'un après l'autre, reconfigurer, compiler, tester. Avec les optimisations, on peut beaucoup plus facilement casser un binaire (même si a priori, la compilation semble finir bien), ne serait-ce que parce que ce sont des options moins utilisées, donc moins testées, du compilateur.
Enfin y a pas mal de trucs qui se font à l'exécution, et non pas à la compilation. Par exemple tu nous dis que t'as une fonction pour savoir le nombre de proc. Donc c'est pour changer ton fonctionnement à l'exécution (par exemple décider du parallélisme de ton code en fonction du nombre de proc, etc). Ça n'impacte pas la compilation; et franchement j'ai jamais vu de ma vie un code où on choisit le nombre de cœurs à la compilation, surtout que de nos jours, y a de tout, même dans le grand public! À chaque sortie de ton logiciel, tu le compilerais 50 fois. C'est pas tenable. X-/
Pareil OpenCL (qu'on utilise aussi dans GEGL, donc dans GIMP) fait du code portable. Si j'ai bien compris (j'ai pas encore touché de code OpenCL, donc il se peut que je dise des bêtises), c'est même l'un des points majeurs d'OpenCL: faire du code portable plutôt que spécifique, tout en permettant de tirer profit du nombre de cœurs à l'exécution, de spécificités de et optimisations pour certains CPU et GPU, etc. Donc pareil, tu gères à l'exécution, pas à la compilation.
J'espère que ça aide.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ben on est sur linuxfr.org, on parle de cross-compiler pour Windows depuis Linux. La toute première phrase de l'article est (emphase rajoutée) « Cross-compiler pour Windows sur une machine Linux est maintenant aussi simple que compiler pour Linux ». Ça parle de bash, zsh. Si tu cliques sur le lien pypi, ça dit que c'est pour "Operating System :: POSIX :: Linux", et si tu lis le README, je dis même que ça n'a été testé que sur une machine GNU/Linux. Donc la réponse est: oui, ça marche avec Linux. :-D
Ou alors tu demandes si ça peut faire l'inverse: compiler pour Linux (comme OS cible) depuis une machine Windows? Et dans ce cas, la réponse est non, mais je me demande bien qui voudrait faire cela alors qu'on a quand même de supers outils natifs pour gérer des sources et compiler sous Linux!
Ou alors tu demandes quelque chose d'autre, et là je pige pas. En fait je pige pas trop ton message.
On les a toutes installees en dynamic sous nos machines, mais nous devons utiliser ce programme dans des endroits ou nous ne pouvons etre root, genre accelerateur de particules.
Crossroad ne nécessite à aucun moment d'être root. Je dirais même plus: ne faites jamais de la cross-compilation en étant root! Je dirais même encore plus-plus (x 100): ne faites jamais — ô grand jamais — du développement en étant root, ni même du simple test de programme! Installez tout sur un préfixe local (mon préfixe usuel pour plein de choses est $HOME/.local par ex, voire un préfixe très temporaire, genre $HOME/test/ quand c'est vraiment juste un test que je veux pouvoir facilement défaire par un rm).
Du coup si je pouvais avoir un bon gros executable ou alors un repertoire qui contient tout et que je peux lancer en local en gerant des variables d'environnement alors cela nous aideriait beaucoup. J'utilise ce Code en ce moment a l'Institut Paul Scherrer et j'ai vriament eu de la chance que les admins soient sympa.
Comme dit plus haut, c'est vraiment pas dur d'installer des logiciels sans être root. Tu mets à jour le PATH de l'utilisateur qui va le lancer (dans bashrc, zshrc, ou autre équivalent selon ton shell, est un emplacement commun pour cela). Pour les libs partagés, tu peux modifier LD_LIBRARY_PATH par exemple (bien qu'il y ait plusieurs solutions, ça dépend de ce que tu veux faire exactement et comment. Jette un œil par exemple là: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Ensuite y a d'autres variables qui peuvent rentrer en jeu. Par exemple pour du Python, tu peux aussi modifier le PYTHONPATH, etc.
Ceci dit, je comprends toujours pas le lien avec le journal qui parle de cross-compilation. :-p
Tes machines cibles sont des Windows? (ça me ferait quand même vachement peur un accélérateur de particule contrôlé par un Windows!)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pour Virtualbox: dans les settings de ta VM, y a un onglet "Shared Folders". Tu cliques dessus, et tu décides d'un répertoire partagé (genre $HOME/shared ou quoi que ce soit qui soit pratique pour toi).
Oublie pas de le mettre en auto-mount (à un moment, je comprenais pas pourquoi la VM d'une amie voyait pas son répertoire partagé. J'ai mis pas mal de temps jusqu'à ce que je remarque que c'était pas en auto-mount).
Il faudra aussi que tu installes les Guest Additions dans ta VM (de toutes façons, t'as intérêt. Sans ça t'as plein de trucs qui marchent pas, et surtout t'auras une résolution qui correspond pas à ton écran, donc l'utilisation sera peu pratique). C'est super facile, VirtualBox a un item dans le menu de la VM, une fois démarrée, qui te permet de télécharger et installer les Guest Additions. Rien à faire d'autre que cliquer et attendre.
Une fois cela fait, tu verras une nouvelle "partition" dans ton Windows au prochain boot, qui sera en vrai le contenu de ton répertoire partagé. Tu pourras donc échanger en direct et en un instant des fichiers de toute taille entre Nux et Win. Et tout lien symbolique dans ce répertoire apparaîtra comme un vrai fichier/répertoire dans Win. C'est juste super pratique.
Pour autre chose que Virtualbox, aucune idée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui c'est justement le build avec lequel j'ai aussi eu le bug!
Comme je le disais, pour moi ça a été réparé en copiant certains binaires d'une version plus vieille (2.22.90.20120919-0ubuntu1+2, celle fournie dans les dépôts de ma Mint).
Mais si tu faisais juste ça pour tester, je peux comprendre que tu n'aies plus envie d'aller plus loin. Par contre si tu as un besoin réel de cross-compiler, mon contournement devrait fonctionner en attendant qu'ils corrigent upstream. :-)
Dans tous les cas, merci pour avoir essayé et donné un retour!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui ça a marché pour toi. C'est sûr, puisque ce bug que tu cites n'apparaît qu'au moment du link. Ça signifie que la compilation s'est passée jusqu'au bout et sans erreur. Seulement tu n'arrives pas à linker avec les libs de MinGW à cause de références manquantes, donc c'est la dernière étape pour faire le binaire final qui foire. C'est con.
Mais tu devrais essayer un des contournement (soit le mien si tu peux trouver un MinGW stable d'avant 3.0, soit essayer de rajouter un #if dans le header comme l'autre rapport de bug propose, et voir si ça corrige aussi).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Merci!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Meilleurs contributeurs LinuxFr.org : les gagnants d'octobre 2013. Évalué à 6.
Merci Linuxfr et merci aux sociétés donatrices.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Tu compiles depuis Win ou en natif?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 3.
Salut,
Même tard, merci pour la réponse. Je ne crois pas qu'on puisse se faire prévenir par email sur linuxfr (et franchement dans les cas où un de nos commentaires innocents déclenchent des discussions déchaînées par certains des trolls sévissant ici, franchement non merci!).
Par contre on peut peut-être continuer la discussion par email. :-)
Ok je réessaierai et je t'enverrai un email directement, avec les messages d'erreur, si ça foire. :-)
C'est peut-être le problème. Je cross-compile sans rien ajouter en "script perso". Normalement un projet devrait bien cross-compiler de la même manière que la compilation native, avec les autotools (on ajoute simplement les options qui vont bien. Je réalise que tes scripts persos, c'est peut-être juste ça: des scripts pour rajouter les options qui vont bien au ./configure et mettre à jour les variables d'environnement. Pour ça j'ai développé mon outil générique en fait: crossroad).
J'arrive parfaitement à cross-compiler la branche gtk-2-24 par exemple sans rien faire spécial (pas tout à fait vrai, j'ai un petit patch en attente, mais une fois ce patch appliqué, c'est bon).
Bon en tous cas, je réessaye pour master, et je te tiens au courant.
Merci pour la réponse.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Tu compiles depuis Win ou en natif?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 4.
Salut Tarnyko,
Si je comprends bien, tu es celui qui maintient ces paquets. J'ai voulu cross-compiler gtk+ master à l'instant, et ça foire. Quand je regarde les Makefile.am, je constate que c'est normal car il y a des règles vraisemblablement manquantes requises par d'autres règles conditionnelles entourées de "if OS_WIN32" (donc ça reste invisible jusqu'à ce qu'on compiles pour Win).
Donc la question que je me pose est: tu compiles avec les autotools ou avec un autre système de build (je vois des makefile.msc qui parle de compiler avec Microsoft C apparemment et je vois des fichiers pour Visual Studio)?
Autre question: tu compiles sous Windows, ou tu cross-compiles?
Merci!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche FFmpeg 2.1. Évalué à 5.
Ahahah. Tu aimes bien dialoguer et argumenter tout seul, même lorsqu'on te dit qu'on est d'accord avec toi.
Et oui j'ai été un peu fort dans mon propos, ce que je n'aime pas faire. Mais c'est vraiment parce que c'est toi. :-D Tu aimes tellement troller juste pour troller que j'ai même plus envie de répondre à tes messages. D'ailleurs c'est ma dernière réponse sur le sujet. Comme j'ai dit, je suis d'accord. À toi de pas me croire et de savoir mieux que moi ce que je pense, si ça t'amuse. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche FFmpeg 2.1. Évalué à 6.
C'est ce que je dis, apprends à lire.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche FFmpeg 2.1. Évalué à 3.
Petit ajout:
Juste au cas donc où j'étais pas assez clair, le bug que j'avais patché était justement qu'a priori le code marchait avec le libav du projet libav, mais pas le libav de ffmpeg que j'avais sur ma machine. Donc ffmpeg n'était pas compatible avec "l'autre" libav.
Note encore une fois: je ne dis pas que c'est de leur faute, et je suis aussi neutre que possible. Je ne prends pas trop parti. C'est juste une constatation et en tant qu'utilisateur, ben on se retrouve avec des bugs, et dire que le libav de ffmpeg est "compatible avec libav" — juste parce que c'est écrit — n'est pas toujours vrai (même si probablement ils essaient, j'ai pas vérifié, mais c'est apparemment ce qui ressort des dires de gens comme toi, et je veux bien vous croire).
C'est pourquoi je dis que la solution n'est pas tenable, et même en choisissant libav comme base en se disant que ça marchera partout (en partant du principe que ffmpeg se dit compatible avec libav), ben on se retrouve avec des bugs. C'est chiant et intenable comme situation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche FFmpeg 2.1. Évalué à 1.
Salut,
J'avais bien compris, et je dis justement que c'est pas suffisant. L'API peut être similaire, mais avec les mêmes arguments justement, un programme se retrouvera cassé selon l'implémentation. C'est le cas dans le bug que j'ai corrigé sur blender où on se retrouvait avec diverses implémentations d'un même codec selon le projet (à l'époque où j'ai patché, j'utilisais l'implémentation libav de ffmpeg!), et on doit tester à l'exécution. Avec les mêmes arguments justement, c'était pas portable de l'un à l'autre, ni réciproquement.
Je donnais des cas réels avec patchs à l'appui. Pas des "morceaux choisis" extraits de doc ou de beaux discours.
Maintenant soyons clair. Je ne dis pas que l'un est mieux que l'autre et je ne jette sûrement pas la pierre à l'équipe de ffmpeg sur le coup. Vu de l'extérieur (de loin, car je ne suis pas vraiment cette histoire, en gros les commentaires dans ton genre ou les blog posts dont les liens sont donnés plus haut sont informatifs pour moi), il semblerait que l'équipe de ffmpeg a en effet un comportement plus sain que ceux de libav, ou du moins font plus d'efforts. Peut-être que le problème que j'avais patché à l'époque n'était qu'une erreur passagère, un oubli, et que depuis l'équipe de ffmpeg a amélioré la compatibilité des codecs avec libav.
Néanmoins je dis juste que tout n'est pas aussi bien et bon avec l'implémentation de ffmpeg qu'ils le prétendent. Probablement pas de leur faute s'ils doivent constamment faire avec une équipe hostile chez libav, mais c'est un fait, appuyé par des patchs ici et là de divers dév, et des logiciels qui cassent, etc.
Pour moi, c'est une situation qui ne peut pas tenir. C'est pas sain. On ne peut pas avoir deux équipes hostiles dont l'une refuse catégoriquement de collaborer avec l'autre, et qui travaillent sur une API de même nom. Même si la première fait énormément d'efforts dans ce sens, les efforts doivent être dans les 2 sens, sinon ça ne peut être que bancal!
Il faut que l'une accepte de renommer ou alors que les deux équipes se mettent finalement d'accord pour collaborer. Et je suis d'accord que ce serait bien plus justifié si le fork (donc le projet libav) était celui qui renomme, car après tout… ben ils sont un fork du premier! Mais de manière évidente (ne serait-ce que par le nom de projet qu'ils ont choisi: libav), il semblerait qu'ils ne veulent vraiment pas et qu'ils sont bornés. Donc je vois pas de solution, mais tout ce que je constate, c'est que la situation est devenue un véritable enfer pour les utilisateurs comme pour les développeurs tiers. Et ce, quelque soit la bonne volonté de l'équipe ffmpeg. Là n'est pas la question.
Les faits sont dans les patchs et les commits des projets, dans les tentatives de compilation, et dans les logiciels qui cassent à l'usage (même en utilisant ffmpeg!), pas dans des "morceaux choisis" sur des sites web.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche FFmpeg 2.1. Évalué à 10.
Je sais pas vraiment ce que signifie "l'inverse n'est pas vrai" (j'entends par là: "ça veut rien dire" car si A fait différent de B, alors B est différent de A). Il s'agit "soi-disant" de deux implémentations de libav, et elles sont différentes. Donc c'est juste pénible. J'ai déjà dû corriger un problème avec des patchs dans deux softwares que j'utilise à cause de différences entre les implémentations: blender et DVDStyler. Et c'est des bugs plus subtils que juste une API différente (en gros, des implémentations différentes de même codecs), donc plus difficiles à repérer et corriger (détection à l'exécution), comme on peut le voir dans mes patchs, ce qui fait que ces bugs ont été présents un moment dans la nature et sont probablement encore présents dans divers logiciels.
Aussi j'ai régulièrement des problèmes avec mplayer depuis que je suis passé sous Mint alors que c'était mon logiciel vidéo phare. A priori c'est parce que les paquetages utilisés sont ceux de libav (alors que les dév mplayer utilisent bien sûr la version de ffmpeg).
Et lorsque j'essaie de compiler certains software qui utilisent libav, j'ai régulièrement des problèmes, selon que les dévs utilisent plutôt une version, et moi une autre.
Franchement c'est juste ridicule. C'est une guerre de gamins. La solution est pourtant simple: s'ils veulent réellement faire différent, très bien! Aucun problème pour moi. Mais renommez. Que l'une des équipes trouve un nouveau nom et on peut installer les deux libs côte-à-côte, et ainsi les divers logiciels choisissent la librairie de leur rêve et les blems sont finis. Je comprends bien que le nom est important pour la notoriété et la base utilisateur, mais c'est pas notre problème! Ils ont fait un choix conscient de forker, ils pourraient assumer jusqu'au bout.
Parce que là en tant que simple utilisateur, on se retrouve pris en sandwich/otage dans une guerre absurde où on nous demande de choisir aussi en gros, sauf qu'en vrai, on nous laisse pas le choix (c'est en général notre distrib qui choisit), et on se retrouve avec des blems sur une moitié des logiciels qui utilisent libav.
Et en tant que dév tier neutre, c'est aussi chiant, car on doit constamment corriger des bugs et des changements pour essayer non plus de suivre 1 librairie, mais pour contourner les différences qui apparaissent progressivement entre 2 librairies qui prétendent être la même sans l'être.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Enfin !!!
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 5.
Pour GIMP, on conseille aux gens d'utiliser le backend Quartz de GTK+ pour OSX (= Cocoa d'après ce que je lis sur le web), car GTK+ sous OSX avec X11 serait vraiment trop mauvais/cassé.
Donc la réponse est "oui, GTK+ marche avec Cocoa", et c'est même conseillé (en tous cas par l'équipe GIMP). Cependant il semblerait que les "ports" (des sortes de paquetages pour OSX, si je pige bien) fournissent plus souvent un GTK+ compilé pour X11. L'autre jour, le designer principal de l'équipe réinstallait GIMP et il a dû compiler GTK+ à la main avec la cible "quartz" (option --with-gdktarget=[x11/win32/quartz/directfb]) à cause de cela.
Tout cela avec beaucoup d'incertitudes dans mes propos, car je n'ai moi-même accès à aucun Mac, donc je ne sais pas à quel point le port Quartz est bien ou non. Et a priori il a aussi pas mal de bugs. Mais il reste mieux que sous X11 pour OSX d'après ce que disent ceux qui utilisent GIMP sous OSX (du moins pour GTK+ 2, car GIMP n'a pas encore migré vers GTK+ 3).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Précision qui m'intérroge
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Tintin tombera-t-il un jour dans le domaine public ?. Évalué à 8.
Sur les exemples cités plus haut? Genre tu crois vraiment que Disney va autoriser quelqu'un à faire un roman sur Mickey à l'œil? Sans demander sa part ou demander à relire et corriger l'œuvre avant publication? Soyons sérieux. Ça peut marcher dans des cas très rares, mais c'est du cas par cas. Dans la majorité des cas, l'auteur originel va essayer de vampiriser le second auteur, ou bien simplement refuser.
Et dans tous les cas, ça n'est pas de l'art. On transforme un processus artistique fluide en négociation business compliquée. J'appellerai pas ça un processus "sain".
Ça, c'est juste de la rhétorique peu subtile. Genre "je suis un connaisseur, j'ai vécu!" pour appuyer tes dires, mais sans donner des détails. Je suis sûr que ça a un nom en rhétorique!
Tu devrais vraiment lire les 2 œuvres que je cite (par exemple) avant de parler de juste "copier" les autres, ou de comparer avec les remakes d'Hollywood. Et encore y en a plein d'autres des bonnes œuvres dérivées de divers œuvres, mais ces deux là sont parmi mes préférées. Des chef-d'œuvres.
C'est peut-être là le problème: tu sembles croire que l'inspiration d'œuvre n'est pas de l'innovation ni de la création. Franchement c'est l'histoire de l'art. Les artistes se sont constamment inspirés et copiés les uns des autres. Par exemple quelqu'un citait Mona Lisa. C'est en effet un des exemples les plus copiés. Il existe même une copie qui a été faite… en même temps que l'original, dans le même studio par un étudiant de Da Vinci (c'est du moins ce que pensent les historiens d'art)!
Cette réplique est visible au Musée Del Prado (Madrid). Tu vas aller leur dire que c'est pas de l'art? Pourquoi il a pas innové et utilisé son propre modèle au lieu de copier?
Et en même temps, tu sembles dire que les comics US sont un bon contre-exemple de gens qui y arrivent parfois. Alors que je trouve au contraire que c'est justement l'exemple de ce qu'il faut pas faire. Ces remakes arrêtent pas de raconter plus ou moins la même histoire, encore et encore. On l'aura compris que les parents de l'un sont morts, ou que cet autre aura été mordu par une araignée! Comment arrives-tu à dire que celui qui raconte complètement une nouvelle histoire (dans les deux œuvres que je cite) en partant de personnages très charismatiques que l'auteur se ré-approprie totalement est de la copie qui "singe" les autres, alors que le même qui raconte pour la 10ème fois l'histoire sans intérêt d'un mec avec des pouvoirs (car c'est là l'intérêt en vrai: on lui fait faire des cabrioles, et il a "même pas mal"!), c'est un bon renouvellement?
Bon je dis pas qu'on peut pas aussi raconter une même histoire en se la ré-appropriant et ce serait aussi une approche artistique. J'essaie juste de te mettre en face de tes contradictions. :p
Tout comme l'étudiant de Da Vinci a ré-interprété Mona Lisa au lieu de se contenter d'essayer de faire un identique.
Ceci dit franchement, citer les comics US comme bon exemple de copie, c'est fort.
Néanmoins je pense qu'on a simplement des valeurs très différentes sur la notion d'art. Mais comme tu dis: "goûts et couleurs".
Dans tous les cas, je vais arrêter là, car je sens que tu ne seras pas d'accord de toutes façons, et j'aime pas faire tourner en boucle les argumentaires. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Précision qui m'intérroge
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Tintin tombera-t-il un jour dans le domaine public ?. Évalué à 5.
Parce que comme tu dis:
Et donc peut-être que des gens aiment le concept de Mickey ou de Tintin, mais pas forcément ce qui sort actuellement, et qu'ils aimeraient pouvoir écrire et vendre leurs propres aventures de Mickey, Tintin, etc. sans demander l'aval (qu'ils n'obtiendront probablement pas, à moins de poser la grosse mallette de billet et d'accepter un droit de regard et de changement sur leur œuvre) de Disney ou autre gestionnaire ayant-droit.
Je pense que j'ai donné 2 très bons exemples plus haut d'œuvres qui n'ont rien à envier aux originaux, mais qui n'auraient probablement pas pu exister s'ils avaient dû demander l'autorisation à une grosse multinationale qui n'a rien à faire d'auteurs indépendants.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Avec Compiz seul.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Cairo-Dock 3.3 prêt à s'installer sur votre bureau !. Évalué à 2. Dernière modification le 23 octobre 2013 à 11:58.
Oui. Mais c'est vrai que c'est dommage que chaque desktop y va de son propre système. Comme Yves, j'avais essayé de configurer le navigateur de fichiers de plein de façons (parce qu'en cherchant des infos sur le web, chaque bureau y allait de sa méthode et même les logiciels XDG, au lieu de la jouer "on impose une logique commune", ils essaient de détecter ton bureau et d'utiliser en priorité les méthodes non standardisée), sans succès. Au final, ça rend des choses simples super compliquées et surtout contradictoires (puisqu'on croit configurer quelque chose, mais on obtient quelque chose de différent). Ce sont des petits détails qui compliquent la vie.
D'ailleurs même ceux qui utilisent des desktop managers, je suis sûr que des fois ils sont perdus. Déjà s'ils ont plusieurs desktops installés. Même sans le vouloir, avec les dépendances de fous de certaines apps, si l'utilisateur fait pas gaffe, il se met à installer un autre desktop. Ensuite il verra plein de progs d'administration "dupliqués" dans son menu, qui ont l'air de faire la même chose. Sans compter les logiciels d'administration de la distrib, qui se retrouvent à faire pareil aussi qu'un logiciel KDE/GNOME/XFCE. Franchement je suis souvent perdu moi-même.
Je regarderai ce que fait le daemon XFCE peut-être.
gnome-settings-daemonfait au moins 2 choses que je recherchais: déjà comme dit plus haut, j'ai des icônes (je m'en fiche un peu desquelles, tant que j'ai pas des icônes cassées); et aussi il charge mon profil de couleur ICC.Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Avec Compiz seul.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Cairo-Dock 3.3 prêt à s'installer sur votre bureau !. Évalué à 2.
Chez moi, ça lance Nemo. J'essaierai la méthode que tu cites dans un message plus bas, sauf que le web me dit que ce serait ~/.local/share/applications/mimeapps.list plutôt que defaults.list? Enfin je verrai.
Mais surtout ce qui me paraît problématique est que ces fichiers semblent davantage fait pour spécifier des .desktop, pas notre propre commande. Déjà ça veut dire qu'on peut pas aisément utiliser un prog sans .desktop (certes, ça devient rare), mais même utiliser un prog qui a un .desktop mais avec des options particulières.
Par exemple,
nemome convient bien à une chose près: il lance aussi un desktop manager par défaut. Or je veux pas de bureau (je lance openbox simple). Je voudrais donc que cairo-dock me lancenemo --no-desktop. Mais comment faire cela en donnant un fichier .desktop? Dois-je créer mon propre .desktop?Aussi n'existe-t-il pas un logiciel de configuration "générique" (= non lié à un desktop en particulier, pour configurer des choses communes, comme ces préfs XDG)?
En fait tu dois configurer le thème de ton bureau toi-même. Comme toi au début, je n'avais pas d'icône dans divers programmes, ni même dans le menu d'application et divers plugins de cairo-dock. J'ai contourné ce problème avec
gnome-settings-daemon &dans mon autostart. Ça ne lance pas un desktop GNOME complet, mais la partie qu'il me fallait. Pas sûr que ça lance pas aussi quelques trucs dont je veux pas, par contre. KDE ou XFCE auront leur propre daemon équivalent. A priori, tu dois être capable de configurer ces trucs toi-même en lisant http://www.freedesktop.org/wiki/Specifications/xsettings-spec/. Mais je t'avoue que je suis pas allé lire cela moi-même. Ma solution actuelle me convient.J'ai créé un rapport de bug chez cairo-dock sur ce sujet précis y a quelques semaines. Et ce fut globalement le résultat.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Qui sera le prochain ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 10. Dernière modification le 23 octobre 2013 à 03:10.
Étant donné que le cœur de GIMP est désormais poussé vers GEGL, cela signifie que GIMP est de plus en plus seulement une UI. Presque tout ce qui concerne le traitement d'image passe dans GEGL. GIMP, c'est donc principalement du code GTK+ lié à du code GEGL (un widget GTK+ appelle telle opération GEGL).
Donc passer en QT n'a pas trop de sens, car ça signifierait en gros tuer 90% du code, je pense. QIMP ne serait donc pas un port de GIMP, mais pourrait tout à fait être une nouvelle application QT faite à partir de zéro, qui utiliserait aussi GEGL (ce qui est fortement encouragé! Plus il y aura d'applications utilisant cette lib commune de traitement d'images, plus celle-ci sera améliorée, avec de nouvelles opérations, plus performante, etc.).
Ceci dit, cela resterait un énorme boulot. Dans un logiciel comme GIMP, l'UI reste très importante. Des logiciels Libres de traitement d'image qui font des trucs de ouf, y en a d'autres, comme ImageMagick, mais beaucoup de gens veulent une UI. Donc ils utilisent GIMP, alors peut-être même que le rendu final d'ImageMagick aurait peut-être plus été ce qu'ils voulaient, ou bien que cela aurait été plus facile pour traiter des lots d'images s'ils avaient pris juste 5 min à lire la doc. Si je me plante pas G'mic aussi a une UI en ligne de commande, mais les gens l'utilisent surtout à travers GIMP (ce qui n'ajoute absolument rien à G'Mic quand seulement ces effets G'mic sont appliqués à l'image). L'UI de GIMP a beaucoup de problèmes et mérite vraiment d'être améliorée radicalement, voire transformée complètement. Mais elle a le mérite d'exister. Toute nouvelle implémentation d'UI (en QT par ex), même s'ils n'auront pas à se préoccuper autant du cœur du programme (en se basant aussi sur GEGL), prendra tout de même énormément de temps et de dédication pour en arriver au même nombre de fonctionnalités que GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Intéressant
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 2.
Batterie de tests pour vérifier des trucs génériques sur des logiciels à cross-compiler ou pour crossroad même?
Si c'est des tests génériques pour des logiciels, non je fournis pas ça avec crossroad. Il ne s'agit que d'un système de compilation, pas un environnement de test.
Si tu parles de tests pour vérifier que crossroad marche, ben le plus simple, c'est de l'installer et l'essayer. J'ai vraiment tout fait pour que ce soit extrêmement facile à installer (avec pip3 notamment, sinon un simple ./setup.py très standard) et utiliser (commandes courtes, faciles à se remémorer, et similaire à une compilation pour le système natif). S'il te manque une dépendance que j'ai pas vue, donc pas citée, tu auras une erreur, et tu pourras me la remonter. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Précision qui m'intérroge
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Tintin tombera-t-il un jour dans le domaine public ?. Évalué à 10.
Franchement c'est comme laisser les ayant-droits décider quoi faire. Ils peuvent faire de la merde (c'est en général le cas), ou des trucs biens (c'est rare. Pour tout dire, j'ai pas trop d'exemple en tête de ce cas!). Pourquoi ces gens seraient-ils plus à même de décider ce qui "préserve" l'œuvre? Par définition, ils ne sont pas les auteurs originels. Donc quoi qu'ils fassent, ils préserveront pas l'œuvre. En fait on ne peut pas "préserver" une œuvre qui n'est pas notre. On peut uniquement "la faire notre". Donc la modifier, la faire évoluer, la transcender. C'est ça l'art. C'est pas essayer de "copier" (souvent en aseptisant, en enlevant des parties "qui plaisent pas", v'là pour la préservation). Tant que ces "ayant-droits" n'auront pas compris ça, ils ne feront jamais rien de bien avec les œuvres dont ils ont les droits. En gros ils agissent plus comme des hommes de loi que comme des artistes (d'ailleurs ils ne se présentent pas comme des "artistes", mais comme des "gestionnaires", ça montre l'ambiance).
Pour tout dire, le fait qu'ils aient exclusivité les pousse même davantage à faire de la merde que du bon, puisque par définition, il n'y a pas concurrence, donc pourquoi se fouler quand on peut faire de l'argent facile? Tu parles de figurine/pub/jouet comme mauvaise utilisation par ex. Ben justement j'ai un peu l'impression que c'est ça ce qu'ils font, pour la plupart des œuvres "gérés" par des ayant-droits. Ou alors des films 3D pour suivre la mode, ou un énième remake nul avec un scénar bidon (mix de plusieurs scénarios et on dit que c'est une nouvelle histoire), et des acteurs célèbres payés à prix d'or.
Au contraire, regarde toutes les œuvres du domaine public. Y a foultitude de dérivés, la concurrence est rude, et y a en effet énormément de trucs peu inspirés (mais ça veut pas dire pour autant que c'était voulu: au moins les auteurs ont essayés. C'est mieux que de faire un truc bidon par le service marketing juste parce qu'on a exclu. Donc je respecte tout de même bien plus leur travail). Mais y a aussi des perles incroyables.
Vois "_Peter Pan_", de Sire Matthew Barry. Un des contes les plus repris dans le monde, partout (même par Disney qui a totalement massacré l'œuvre). Beaucoup de trucs bidons. Mais dans le lot, y a au moins une véritable œuvre d'art qui a non seulement gardé beaucoup de l'esprit (tout le côté un peu torturé de Peter Pan, avec la fée vraiment malsaine, le fait que les enfants imaginaires sont peut-être pas si heureux que ça, le côté "rester enfant à jamais" pas si bon-enfant justement, car les enfants sont très cruels, le pays imaginaire lui-même pas aussi bien qu'il apparaît au début, notamment la tristesse d'oublier tout, même les bons moments, etc.), tout en renouvelant complètement avec l'histoire de la création de Peter Pan, au lieu de faire un énième remake massacré: "_Peter Pan_" de Loisel. Cette BD est un chef d'œuvre.
Quant à "_l'Île au Trésor_", de Stevenson, lui aussi repris à toutes les sauces et sous de nombreuses formes. J'ai lu un des meilleurs romans que j'ai jamais lu il y a quelques années: "_Long John Silver_", de Björn Larsson. C'est le roman autobiographique du pirate Long John Silver. Et c'est extraordinaire. Le roman originel est sympa, c'est à lire, ne serait-ce que parce que c'est un classique. Bon c'est un peu un roman pour enfant, mais ça se lit bien. Mais le "_Long John Silver_" de Larsson transcende l'original (d'après moi. Bien sûr ça reste un avis perso). Et je suis vraiment content que l'originel soit passé dans le domaine public. Sans cela, l'humanité serait passée à côté d'un chef d'œuvre, un vrai bijou de la littérature. C'est vraiment une très bonne évolution d'une œuvre que je qualifierais originellement de juste "agréable à lire pour passer le temps". Encore heureux que personne a cherché à "préserver" une quelconque "forme" qui n'a de toutes façons jamais existée.
Tout ça pour dire que cette raison est mauvaise au mieux, mais surtout bidon.
Je rappelle que vous pouvez trouver les originaux de diverses œuvres du domaine public sur Wikisource et le Projet Gutenberg.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ca marche avec Linux ??
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 6.
Mais je pige pas vraiment non plus pourquoi tu penses avoir besoin de recompiler pour des libs statiques. Les paquetages de développement sur les distribs que je connais fournissent aussi les libs statiques. Pas seulement les dynamiques. C'est le cas sur ma Linux Mint (donc Ubuntu aussi). Je suis à peu près sûr que c'était aussi le cas sur ma Mageia. Etc.
L'auteur du journal, c'est moi, au passage.
On appelle ça le gestionnaire de paquets sous Linux! :-p Plus sérieusement, je comprends pas trop le problème. J'ai l'impression que tu dis que j'arrive à faire un truc pour Windows avec
crossroadqu'on n'a pas pour Linux en temps normal. Mais c'est l'inverse. On a le gestionnaire de paquet pour Linux. Et avec crossroad, je ne fais que reproduire le concept pour Windows. Mais pour Linux, ben ça existe déjà! Rien à reproduire!Es-tu en train de dire que tu écris ton Makefile entièrement à la main? Si c'est le cas, ne cherche plus. Je crois qu'on a trouvé ton problème. Faire un Makefile entièrement à la main n'est plus une option viable pour n'importe quel projet qui dépasse le jouet. Tu fais ça au début pour apprendre ce qu'est un Makefile, mais ensuite pour un vrai projet, avec des dépendances, tu génères ton Makefile avec des outils qui vont tout faire pour toi. Que ce soit les autotools, cmake, qmake, ou quoi que ce soit. On n'écrit pas de code spécifique pour gérer des libs statiques et pourtant les Makefile générés par les autotools/cmake sont capable de générer soit du dynamique, soit du statique, soit les deux à la fois!
Oulah! Tu parles complètement d'autre chose là. Ça fait des années que j'ai plus touché matlab, mais au dernières nouvelles, il s'agit de code interprété. Tu peux aussi bien écrire du code matlab sur Linux si tu veux, et il sera tout aussi portable. Pareil pour n'importe quel language interprété. Ça n'a rien à voir avec des problèmes de chaîne de compilation, ni avec l'OS ou le fait que c'est proprio ou libre.
Franchement je crois bien que s'il y a un point où on n'a pas à rougir, c'est notre chaîne de compilation et les divers outils de gestion de projets. C'est pas pour rien qu'on cherche à cross-compiler sur Linux pour Windows, même si on a accès à un Windows (en VM par ex pour moi): car c'est 100 fois plus simple sous nux!
Je ne suis pas la moindre des discussions sur linuxfr, mais je me demandes si tu ne cites pas là un tout autre sujet, qui est celui des gestionnaires de paquetage, pas la chaîne de compilation.
Franchement je crois que votre bêtise fut d'écrire apparemment vos Makefile à la main (si j'arrive bien à lire entre tes lignes. Désolé si je me plante). Je vous conseille de passer un peu de temps pour réécrire la chaîne de compilation de votre projet. Lisez des tutos cmake ou autotools, et choisissez l'un des deux (ou un autre, je suis pas sectaire).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Cross compiler vers du matériel différent ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 4.
À la compilation, tu peux pas configurer ce que le binaire fera à l'exécution. La seule chose que tu peux faire, c'est compiler plusieurs versions de ton logiciel, et installer chaque version sur la bonne machine. Chaque binaire aura un code machine différent (soit parce que le code source est différent et sélectionné par des commandes pré-processeur, soit parce que le compilateur va générer un code machine différent pour le même code source).
Si tu veux un seul binaire commun qui fait diverses choses selon l'architecture précises, on revient sur des librairies d'abstraction, comme OpenCL et compagnie avec une logique dans le code. Faut pas que tu mélanges les deux. C'est complémentaire.
Et de manière général, il n'y a pas de magie. Le multi-tâche (threading, multi-proc, etc.), c'est dans le code. Ça peut être plus ou moins encapsulés dans des librairies haut niveau, mais ça reste au dév de créer la logique. Une option du compilateur pour créer du code parallèle à partir de code linéaire, ça n'existe pas.
Donc ce genre de choses n'a vraiment rien à voir avec la compilation (bien sûr y a des options de compilation en rapport avec le multi-thread, mais c'est pas pour transformer magiquement ton code), et donc avec crossroad.
La seule chose qui a un rapport, c'est quand tu parles de générer des sets d'instructions plus précis que juste x86 32/64-bit. Comme dit plus haut, fais un
man gcc. Et fais une recherche avec tes mots clés. Je trouve des trucs pour NEON (-mfpu=neon), plein de mentions de SSE (plein d'options, à toi de choisir lesquelles tu veux), pareil pour AVX. Ça oui, tu peux rajouter ces options dans ton CFLAGS (donc probablement aussi fonctionnel avec crossroad).Et encore même pour ça, ça ne signifie pas que le code final va soudainement être parfaitement optimisé. Le compilateur va tenter de générer des codes spécifiques plus performants s'il détecte des schémas connus. Et pour ça les compilos modernes sont très forts et peuvent être plus performants que la plupart des dévs. Mais une machine reste moins intelligente qu'un humain malin. Et il est donc possible que tu puisses optimiser davantage avec du code assembleur (comme il est aussi possible que tu fasses pire que l'optimisation du compilo).
Pour tout le reste, c'est à toi de bosser et de modifier ton code. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ca marche avec Linux ??
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 3.
Qu'appelles-tu "refaire tout le travail de makefile"? Entends-tu "modifier" le makefile? Parce que normalement tu ne devrais pas avoir à toucher aux Makefile. Il y a en général une option pour compiler la librairie en statique (--enable-static ou équivalent). Je ne compile jamais en statique, mais je sais que ça devrait être tout aussi simple qu'en dynamique.
Ça te permettrait en effet d'avoir un gros binaire avec tout dedans et ça résoud le problème.
Comme dit plus haut, tu peux tout à fait installer tout dans un préfixe de ton choix. Donc "si", tu sais ce que tu auras quand tu arriveras. :-)
Bien sûr, je ne conseillerais pas normalement ce type de procédure pour une belle install propre, avec des libs partagées par divers programmes, etc. Mais si cela te convient et peut te permettre de contourner l'administration trop procédurière, faire gagner des semaines de boulot à tout le monde, alors pourquoi pas.
En gros tu crées ton préfixe perso. Par exemple $HOME/nomduprojet/ et tu compiles tous tes programmes avec --prefix=$HOME/nomduprojet/
Tu voudras probablement temporairement changer ton $PATH, $ACLOCAL_FLAGS, $PKG_CONFIG_PATH, $LD_LIBRARY_PATH, etc. relativement à ce préfixe, bien sûr.
Au final l'ensemble du projet et toutes les dépendances seront inclus dans ce préfixe. Tu n'auras alors qu'à compresser le répertoire et envoyer tout ce qu'il y a dedans sur ta machine cible. Puis sur ta machine, tu décompresses où tu veux, et tu mets à jour le PATH et le LD_LIBRARY_PATH. En général, il n'est même pas nécessaire d'avoir les mêmes qu'à la compilation. Je dis "en général" car selon le programme, il est possible que le préfixe de compilation se retrouve dans des fichiers de conf, voire même dans des binaires compilés. Donc ça reste du cas par cas, un peu dangereux, et il est quand même préférable de savoir quel sera le préfixe final. Mais juste savoir le préfixe que tu peux utiliser, ça ne doit pas être si dur à savoir, non?
Normalement tes admins devraient savoir tout ça ceci dit! Je comprends pas pourquoi tu te retrouves à faire cela si c'est pas ton boulot. Les admins devraient te dire ce dont ils ont besoin. C'est leur boulot.
Ça c'est vraiment pas un blem. Sauf si ton programme est censé avoir accès à des ressources systèmes interdites aux utilisateurs (parce que ça peut faire tout pêter, ou bien parce que ça peut donner des infos sur les autres utilisateurs, par ex). Dans ce cas, il te faut être root à un moment donné pour au minimum faire un setuid. Mais la plupart des programmes utilisateurs n'ont pas ce cas d'usage et peuvent tout à fait être installés sans le moindre droit par un utilisateur normal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ca marche avec Linux ??
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 2.
Salut,
Ben je prends tout patch pour le support de qmake dans crossroad. Si tu me le fais, je l'intègre! :-)
Ou alors faudra attendre que je tombe sur un projet qmake que je veuille cross-compiler (mais ça peut prendre très longtemps! J'utilise pas qmake pour mes projets, et je tombe rarement sur des projets qmake).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Cross compiler vers du matériel différent ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 4.
Salut,
Même lorsqu'on compile pour sa propre plateforme, on compile très rarement pour une architecture très précise. En gros, ceux qui font cela sont par exemple les gens sous Gentoo, ou bien des fous de l'optimisation. J'imagine aussi que dans le monde des jeux vidéos ultra-performants (c'est juste une hypothèse, je sais pas s'ils font vraiment ça), les dévs vont compiler plusieurs versions pour les processeurs et CG majeurs, et vont embarquer ainsi toutes ces versions alternatives dans leur installeur qui détectera en temps réel et installera une version optimisé si possible (une version plus générique sinon).
Mais à part ça, les développeurs se contentent de fournir deux versions pour x86 (une 32 et une 64-bit), pareil pour Mac, et pour Linux, etc. (ça fait déjà pas mal de versions!)
Et encore certains se contentent de 32-bit en se disant que de toutes façons, tous les OS 64-bit ont un layer de compatibilité 32-bit. Voire même livrent le binaire Win pour Nux en embarquant Wine. On a tous vu ça, n'est-ce pas?
Donc
./configure, même si la cible est ta propre plateforme, va fournir par défaut un binaire générique (c'est à dire un code non optimisé pour le plus petit dénominateur commun similaire à ta machine, par ex "tout processeur x86 32-bit"), et non un binaire optimisé pour ton proc exact. Parce que c'est ce que la plupart des gens veulent. Si tu veux du code spécifique, tu dois spécifier explicitement l'architecture à ton compilateur. Par exemple, fait unman gcc. Regarde des options du type -march, -mcpu, -mtune, déjà. Et encore ça c'est de la petite optimisation. Après chaque architecture a son propre lot d'options spécifiques pour aller plus loin, activer ou non des fonctionnalités, etc. Normalement tu vas activer de telles options en modifiant ton CFLAGS pour C, CXXFLAGS pour C++, etc.J'en dirais pas plus parce que je suis loin d'être un pro de l'optimisation. Le plus loin que j'ai fait, c'est quand j'utilisais Gentoo, et encore je me contentais de spécifier l'architecture processeur.
En général, je fais plutôt comme tout le monde: je fais simple et compile générique. :-)
Donc est-ce que crossroad peut aussi compiler avec des optimisations? Ben j'ai pas testé, mais étant donné que MinGW-w64 se base sur gcc, je pense que oui. J'imagine qu'il suffit de choisir tes options, faire divers CFLAGS pour les diverses architectures particulières que tu veux, puis faire un
export CFLAGS="-some-great-optimization -another"(tu fais unman gccet tu fais ton marché). Bien sûr, fait ça avant de commencer à configurer (crossroad configure) et compiler pour que ce soit bien pris en compte.En outre je te conseille fortement d'ajouter tes flags l'un après l'autre, reconfigurer, compiler, tester. Avec les optimisations, on peut beaucoup plus facilement casser un binaire (même si a priori, la compilation semble finir bien), ne serait-ce que parce que ce sont des options moins utilisées, donc moins testées, du compilateur.
Enfin y a pas mal de trucs qui se font à l'exécution, et non pas à la compilation. Par exemple tu nous dis que t'as une fonction pour savoir le nombre de proc. Donc c'est pour changer ton fonctionnement à l'exécution (par exemple décider du parallélisme de ton code en fonction du nombre de proc, etc). Ça n'impacte pas la compilation; et franchement j'ai jamais vu de ma vie un code où on choisit le nombre de cœurs à la compilation, surtout que de nos jours, y a de tout, même dans le grand public! À chaque sortie de ton logiciel, tu le compilerais 50 fois. C'est pas tenable. X-/
Pareil OpenCL (qu'on utilise aussi dans GEGL, donc dans GIMP) fait du code portable. Si j'ai bien compris (j'ai pas encore touché de code OpenCL, donc il se peut que je dise des bêtises), c'est même l'un des points majeurs d'OpenCL: faire du code portable plutôt que spécifique, tout en permettant de tirer profit du nombre de cœurs à l'exécution, de spécificités de et optimisations pour certains CPU et GPU, etc. Donc pareil, tu gères à l'exécution, pas à la compilation.
J'espère que ça aide.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ca marche avec Linux ??
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 5.
Salut,
Ben on est sur linuxfr.org, on parle de cross-compiler pour Windows depuis Linux. La toute première phrase de l'article est (emphase rajoutée) « Cross-compiler pour Windows sur une machine Linux est maintenant aussi simple que compiler pour Linux ». Ça parle de bash, zsh. Si tu cliques sur le lien pypi, ça dit que c'est pour "Operating System :: POSIX :: Linux", et si tu lis le README, je dis même que ça n'a été testé que sur une machine GNU/Linux. Donc la réponse est: oui, ça marche avec Linux. :-D
Ou alors tu demandes si ça peut faire l'inverse: compiler pour Linux (comme OS cible) depuis une machine Windows? Et dans ce cas, la réponse est non, mais je me demande bien qui voudrait faire cela alors qu'on a quand même de supers outils natifs pour gérer des sources et compiler sous Linux!
Ou alors tu demandes quelque chose d'autre, et là je pige pas. En fait je pige pas trop ton message.
Crossroadne nécessite à aucun moment d'être root. Je dirais même plus: ne faites jamais de la cross-compilation en étant root! Je dirais même encore plus-plus (x 100): ne faites jamais — ô grand jamais — du développement en étant root, ni même du simple test de programme! Installez tout sur un préfixe local (mon préfixe usuel pour plein de choses est $HOME/.local par ex, voire un préfixe très temporaire, genre $HOME/test/ quand c'est vraiment juste un test que je veux pouvoir facilement défaire par un rm).Comme dit plus haut, c'est vraiment pas dur d'installer des logiciels sans être root. Tu mets à jour le PATH de l'utilisateur qui va le lancer (dans bashrc, zshrc, ou autre équivalent selon ton shell, est un emplacement commun pour cela). Pour les libs partagés, tu peux modifier LD_LIBRARY_PATH par exemple (bien qu'il y ait plusieurs solutions, ça dépend de ce que tu veux faire exactement et comment. Jette un œil par exemple là: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Ensuite y a d'autres variables qui peuvent rentrer en jeu. Par exemple pour du Python, tu peux aussi modifier le PYTHONPATH, etc.
Ceci dit, je comprends toujours pas le lien avec le journal qui parle de cross-compilation. :-p
Tes machines cibles sont des Windows? (ça me ferait quand même vachement peur un accélérateur de particule contrôlé par un Windows!)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question de noob
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 3.
Pour Virtualbox: dans les settings de ta VM, y a un onglet "Shared Folders". Tu cliques dessus, et tu décides d'un répertoire partagé (genre $HOME/shared ou quoi que ce soit qui soit pratique pour toi).
Oublie pas de le mettre en auto-mount (à un moment, je comprenais pas pourquoi la VM d'une amie voyait pas son répertoire partagé. J'ai mis pas mal de temps jusqu'à ce que je remarque que c'était pas en auto-mount).
Il faudra aussi que tu installes les Guest Additions dans ta VM (de toutes façons, t'as intérêt. Sans ça t'as plein de trucs qui marchent pas, et surtout t'auras une résolution qui correspond pas à ton écran, donc l'utilisation sera peu pratique). C'est super facile, VirtualBox a un item dans le menu de la VM, une fois démarrée, qui te permet de télécharger et installer les Guest Additions. Rien à faire d'autre que cliquer et attendre.
Une fois cela fait, tu verras une nouvelle "partition" dans ton Windows au prochain boot, qui sera en vrai le contenu de ton répertoire partagé. Tu pourras donc échanger en direct et en un instant des fichiers de toute taille entre Nux et Win. Et tout lien symbolique dans ce répertoire apparaîtra comme un vrai fichier/répertoire dans Win. C'est juste super pratique.
Pour autre chose que Virtualbox, aucune idée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Petit test
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 3.
Salut,
Oui c'est justement le build avec lequel j'ai aussi eu le bug!
Comme je le disais, pour moi ça a été réparé en copiant certains binaires d'une version plus vieille (2.22.90.20120919-0ubuntu1+2, celle fournie dans les dépôts de ma Mint).
Mais si tu faisais juste ça pour tester, je peux comprendre que tu n'aies plus envie d'aller plus loin. Par contre si tu as un besoin réel de cross-compiler, mon contournement devrait fonctionner en attendant qu'ils corrigent upstream. :-)
Dans tous les cas, merci pour avoir essayé et donné un retour!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 3.
Oui ça a marché pour toi. C'est sûr, puisque ce bug que tu cites n'apparaît qu'au moment du link. Ça signifie que la compilation s'est passée jusqu'au bout et sans erreur. Seulement tu n'arrives pas à linker avec les libs de MinGW à cause de références manquantes, donc c'est la dernière étape pour faire le binaire final qui foire. C'est con.
Mais tu devrais essayer un des contournement (soit le mien si tu peux trouver un MinGW stable d'avant 3.0, soit essayer de rajouter un #if dans le header comme l'autre rapport de bug propose, et voir si ça corrige aussi).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]