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 ]
Peut-être. Ça y ressemble en tous cas. Tu peux essayer de modifier les headers dont parle le gars en rajoutant ce #if. Si ça règle le problème, c'est probablement le même.
J'avais vu ce rapport de bug en effet, mais j'en avais créé un autre car j'avais aussi d'autres erreurs (comme je dis dans mon rapport) et je dois pas toucher que la lib crt mais une autre aussi. Mais peut-être que les autres erreurs étaient seulement des conséquences du premier et que si on rajoute ce #if, ça corrige toutes les erreurs?
Je ne sais pas. J'ai pas regardé dans le code. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Les dépendances pré-compilées sont fournies par le projet Fedora. Je me sers juste dans leur repo, décompresse et installe dans un répertoire que je crée et dont je me sers comme préfixe.
Pour installer ta propre lib (perso, ou non disponible dans les dépendances pré-comp), tu la compiles et l'installes avec crossroad (crossroad configure && make && make install), tout simplement. Cela l'installera dans le même préfixe que tout le reste [*], mélangé avec les libs pré-compilées et ton projet final. Comme l'environnement est normalement bien configuré, le projet qui nécessite cette lib la verra lors de l'étape de configuration. En gros tu devrais retrouver exactement la même expérience que lorsque tu compiles ton projet et ses libs pour Linux.
Le plus simple est d'essayer, et tu verras, ça vient naturellement pour qui compile régulièrement (ça n'apprend pas magiquement la logique de compilation à ceux qui comprennent pas ce qui se passe quand ils font un ./configure, make et make install, bien sûr).
À propos, c'est pas que C et C++ théoriquement. Ma distrib fournit aussi des paquets nommés gnat-mingw-w64-x86-64, mingw-ocaml, gobjc++-mingw-w64-x86-64, et gfortran-mingw-w64-x86-64. J'en déduis qu'on devrait être capable de cross-compiler aussi en Ada, Objective C++, Objective Caml et Fortran. Et en fait j'ai déjà ajouté le code nécessaire dans crossroad. Donc si tu installes les dépendances adéquates, tu devrais pouvoir compiler une tripotée de projets différents.
Cela étant dit, je dis "théoriquement", car je n'ai compilé que des projets C et C++ moi-même avec crossroad. Je n'ai jamais testé les autres langages en cross-comp, donc j'ai peut-être (probablement même!) loupé des trucs pour que ça marche (des variables d'environnement déjà très probablement, etc.).
Néanmoins j'invite à tester quiconque en a besoin et je me ferai un plaisir de corriger crossroad quand je recevrai des rapports de bug pour d'autres langages (si possible avec des infos sur ce qui manque si vous le savez déjà).
[*] crossroad ne fait pas du multi-préfixe car le but n'est nullement de reproduire un arbre complexe de préfixes dans ton Windows. Ça fait un unique préfixe et tout est dedans.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai testé un peu et j'ai trouvé ce que je pense être un bug. Le répertoire .cache/crossroad/prefix n'est pas créé et à un moment, ça pose problème, ça finit en exception.
Bien trouvé. C'est pourquoi on devrait toujours réinitialiser son environnement de travail (cache, fichiers de config, etc.) pour tester convenablement un nouvel outil! :p Comme j'avais ce rép depuis longtemps, j'ai dû introduire un bug et ai oublié de tout détruire pour avoir un environnement vierge, comme un nouvel utilisateur. Merci pour le rapport. Corrigé et poussé maintenant. Je ferai une release mineure bientôt.
/usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/lib/crt2.o:
dans la fonction « __tmainCRTStartup »:
/tmp/buildd/mingw-w64-3.0.0/build/x86_64-w64-mingw32-x86_64-w64-mingw32-crt/../../mingw-w64-crt/crt/crtexe.c:285:
référence indéfinie vers « set_invalid_parameterhandler »
Oui j'ai eu exactement la même. C'est un bug de mingw. Simplement des fonctions a priori oubliées dans les libs. Donc ça compile, mais ça foire au link.
T'utilises quelle version de MinGW-w64? J'avais eu ce problème avec le dernier build nocturne automatique. J'ai même fait un bug report: https://sourceforge.net/p/mingw-w64/bugs/350/
Tu peux voir exactement le même bug que toi dans le config.log que j'ai attaché au ticket.
Comme j'avais aussi d'autres bugs de macros non définis dans des headers sur le MinGW-w64 stable plus vieux fourni par ma distro, j'utilise actuellement une sorte de mix immonde. J'utilise le build nocturne dans lequel j'ai remplacé les binaires libmingw32.a, libmingwex.a et crt2.o depuis le vieux build stable de ma distro (2.22.90.20120919-0ubuntu1+2).
Ça marche nickel. Je conseille donc de faire ainsi en attendant le fix.
N'hésite pas à reporter que t'as eu la même erreur dans le bug report. :-) Peut-être que cela poussera le bug dans les priorités si on est plusieurs à le rapporter.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Merci pour elle pour tous les commentaires. C'est une vraie composition, avec une vraie tarte, assiettes, tasse, etc. qu'elle a placés dans cette position spécifiquement pour ce dessin. Mais oui elle a aussi fait une photo car elle dessine sur l'ordi, un portable avec un gros écran et sa grande tablette graphique, donc c'est assez dur de rester constamment dans un bon angle de vision de l'original. C'est à la fois un des inconvénients (l'encombrement) et des avantages (on peut trimbaler une représentation photographique) du numérique.
Par contre elle ne dessine pas par dessus la photo. Elle est partie d'un canvas blanc et a dessiné dessus avec une brosse numérique le moindre pixel. La photo ne servait que de référence de comparaison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Cool, tiens moi au courant si tu essaies crossroad. Tout retour d'utilisation est bienvenu.
En tous les cas, pour les projets un peu gros, je pense qu'il vaut mieux régulièrement au moins compiler dans d'autres OS dès le début (même si on ne teste et que le port est pas pour l'immédiat. Ça ne coûte pas grand chose — avec un tel outil — au minimum de juste cross-compiler et voir que ça le fait sans erreur). À mon avis, même en faisant attention, le diable est dans les détails comme on dit. Mais bien sûr, les corrections seront bien plus simples et minimes si tu as essayé d'être portable dès le début. Et peut-être même qu'il n'en aura aucune, qui sait?!
Merci pour la faute de voc. Il semblerait que tu aies raison. Ces dernières années, j'ai parlé plus souvent anglais ou japonais que français. Forcément ça joue des tours. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ça a l'air cool. J'aime et ai toujours aimé Gentoo, c'est ma distribution préférée pour et la plus agréable à l'utilisation… hormis pour le temps qu'on y passe! C'est d'ailleurs la seule raison pour laquelle je ne l'utilise plus sur ma machine principale. Je veux plus passer des heures à compiler.
Ceci dit, le problème majeur de crossdev, c'est que c'est encore un outil de distribution = pour cette distribution seulement. C'est cool pour les utilisateurs de la distrib, mais chiant pour les autres. crossroad se veut générique. Je l'ai commencé sur ma Mageia 3, puis le continue sur ma Linux Mint. Et je veux pouvoir cross-compiler aisément quelque soit ma prochaine distrib, si je venais à changer encore.
Fedora (et Suse bien sûr par conséquent!) aussi ont des outils facilitant la cross-compilation, avec un wrapper de ./configure aussi, je crois (si je me souviens bien, j'avais regardé un tuto y a longtemps, mais n'ai jamais testé car j'ai pas de Fedora/Suse justement). C'est pareil. C'est du spécifique à une distrib, donc inintéressant pour moi.
Apparemment crossdev est intégré à portage et permet donc de compiler l'ensemble de l'arbre de dépendances de Gentoo dans n'importe quel plateforme cible fournie par Gentoo. C'est vraiment cool. Ça permet définitivement plus de choses que crossroad puisque je fais que du Windows sur x86 32 et 64-bit pour le moment. Et ma liste de dépendances est limitée à ce que le projet Fedora veut bien pré-compiler, ce qui est forcément moins que l'ensemble des paquetages de Gentoo. Mais c'est bien le principe de Gentoo où on compile déjà tout de toutes façons. Ben là on peut compiler tout à nouveau, mais simplement pour une autre plateforme. :-)
Mais bien sûr cela marche ainsi parce que c'est intimement lié à portage, donc à Gentoo. Et cela reste un système de cross-compilation que je ne pourrai pas essayer de sitôt.
Et puis j'espère bien élargir bientôt le champs des possibilités de crossroad pour compiler vers d'autres plateformes!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Moi j'ai toujours entendu dire que ça dépendait du pays. D'ailleurs les sites web qui diffusent du domaine public ont en général toujours un avertissement disant que le domaine public est connu pour un pays X (en général le pays du projet), et vous demandant de vérifier les lois du copyright dans votre pays — si différent — pour être sûr de pas enfreindre la loi.
Ceci dit, je viens de regarder Copyright sur Wikipedia. Ça dit ça:
En vertu de la Convention de Berne, la durée typique de la protection du droit d'auteur est de 50 ans pour la date de publication6. Il s'agit d'un défaut - les lois nationales sont généralement supérieures à cette durée.
Donc tu as raison pour dire qu'il y a un accord international (sur 166 pays apparemment), mais comme toujours avec les lois internationales, les lois nationales prévalent. Or les pays légifèrent souvent des durées plus longues (jamais plus courtes, semblerait-il!).
Ceci dit, cela voudrait dire que Mickey Mouse, protégé par le Mickey Mouse Protection Act aux US, n'est plus protégé ailleurs, M. Disney étant mort il y a plus de 50 ans… si quelqu'un peut apporter une contradiction, j'en serais très heureux !
Ben moi j'en suis vraiment pas heureux, mais la loi que tu citais est justement la contradiction. Tu l'avais donc apportée toi-même! D'ailleurs c'est pour cela que les gens l'appellent du sobriquet "Mickey Mouse Protection Act", puisqu'elle est le résultat des coups de pouce de Disney vers le gouvernement pour justement que Mickey ne passe pas dans le domaine public.
En gros si je comprends bien cet acte d'extension déjà prolonge les droits d'auteur à 70 ans par défaut. Puis fait un cas spécial pour les œuvres d'entreprise (comme Mickey!) qui passent soit à 95 ans après publication ou 120 ans après création (le plus long est choisi!). Donc malheureusement Mickey est loin d'être dans le domaine public, du moins pas pour ceux qui habitent aux US.
Pour en savoir plus, va lire l'article que tu pointes sur Wikipedia. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
d. Use with Virtualization Technologies. Instead of using the software directly on the licensed
computer, you may install and use the software within only one virtual (or otherwise emulated)
hardware system on the licensed computer. When used in a virtualized environment, content
protected by digital rights management technology, BitLocker or any full volume disk drive
encryption technology may not be as secure as protected content not in a virtualized
environment. You should comply with all domestic and international laws that apply to such
protected content.
Donc oui on a bien le droit (bien sûr ça s'applique parce que je n'utilise pas mon Win sur la plateforme matérielle, où j'ai un Linux).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
La légende concerne les deux personnages. Comme tu le dis toi-même, Robert Johnson a une autre chanson où le diable est cité explicitement: "Me and the Devil Blues".
Quant à "Cross Road Blues", même si le diable n'est pas explicitement nommé, toutes les interprétations convergent vers l'histoire de la rencontre avec le diable. Et les paroles sont tout de même assez perturbantes dans ce sens. Ça parle du fait qu'il est à la croisée des chemins et fait du stop, mais personne le prend en stop. Pendant ce temps, la nuit se met à tomber, et il a vraiment peur. À la fin il dit "I believe I'm sinking down", ce qu'on peut comprendre par le fait qu'il croit être perdu. Peut-être parce qu'il est trop tard pour lui, trop tard pour sauver son âme?
Dans tous les cas, je vois pas pourquoi le fait qu'il y ait aussi des histoires sur Tommy Johnson, cela interdirait aussi celles sur Robert Johnson. A priori des historiens pensent que l'un comme l'autre aimaient à entretenir eux-même ces légendes. C'était un bon marketing déjà, en tant que bluesmen. Aussi ils étaient l'un comme l'autre assez connus pour être plutôt roublard. Certaines interprétations du caractère de Robert Johnson laissent penser qu'il pensait que ça le protégeait ainsi que les gens puissent penser qu'il ait un lien avec le diable. Car si on a peur de lui comme associé du diable, oserait-on s'en prendre à lui (probablement oui, car on pense que sa mort pourrait être dû à un mari jaloux, qui n'aurait donc pas eu suffisamment peur de la légende!)?
Dans tous les cas, une chose est sûre: de nos jours, la légende du pacte avec le diable concerne ces deux personnages. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je connaissais pas MXE. Mais je viens de jeter un œil.
Déjà MXE maintient sa propre liste de paquetage de dépendances. D'une, ça doit être un travail de dingue de les garder à jour et vérifier que chacun compile proprement à chaque nouvelle version; de deux, je suis persuadé qu'il n'est pas à jour sur plein de paquetages à cause du premier point (sauf si l'équipe est vraiment grosse?); de trois, même si l'installation des dépendances reste simplifiée certes par rapport à tout faire à la main, il n'empêche que tu te tapes des dizaines de compilations pour un gros projet.
Quand je compile GIMP par exemple, j'ai pas compté, mais avec les dépendances de dépendances, je pense qu'y a bien une vingtaine au moins de paquets installés. Ben ça se fait en genre une minute. C'est du pré-compilé. Donc c'est rapide, et surtout ça marche tout le temps. Le seul cas où une installation de dépendance foire avec crossroad, c'est si les serveurs Fedora sont down. :-)
MXE, ils compilent tout sur l'ordi de build. Donc c'est lent, et ça peut foirer (car on sait tous que les compilations, c'est pas parce que ça marche bien chez le dév que ça marche chez vous (même si c'est normalement le but recherché). Y a beaucoup plus de paramètres en compte.
Et surtout je ne me charge pas de cette liste de dépendances! Donc j'en ai genre probablement bien plus que MXE sans rien avoir à faire. Crossroad va simplement télécharger la liste des paquets Fedora dès que tu l'invoques et est donc toujours à jour par rapport à la dite liste.
Voici donc la liste complète des dépendances de Crossroad: http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_12.3/noarch/
MXE a ça apparemment: https://github.com/mxe/mxe/tree/master/src
C'est pas mal aussi, et j'ai pas compté précisément pour voir qui a la plus grosse. Mais je préfère de loin ne pas avoir à me préoccuper de cela.
Pareil j'ai l'impression que MXE va jusqu'à lui-même compiler MinGW ou MinGW-w64. Franchement toutes les grosses distrib ont MinGW/MinGW-w64 d'installable pour ton OS. Et si vraiment tu veux une version plus récente, y a des builds nocturnes officiels aussi (en tous cas pour MinGW-w64). Vraiment pourquoi s'embêter à compiler ça?
Tout comme les dépendances, je préfère de loin déléguer.
Pour le reste, si tu regardes le tuto de MXE, ça aide pas beaucoup plus que cela. J'ai l'impression que son point principal, c'est de proposer des Makefile pour diverses dépendances.
Mais ils te demandent toujours de modifier tes variables d'environnement et de taper les configure et cmake à rallonge. C'était justement la partie chiante que je suis content d'avoir automatisé. Après tout, c'est toujours les mêmes options. Pourquoi me faire chier à les taper ou copier-coller à chaque fois plutôt que les automatiser dans un script?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Mon outil configure le projet pour s'installer dans un préfixe donné, ainsi que toutes les dépendances pré-compilées (car on veut pas mélanger des binaires Win avec son OS). Dans la pratique, ça rajoute simplement un --prefix automatique à ton ./configure pour qu'on ait pas à y penser à chaque fois.
Ce crossroad --symlink est juste un petit raccourci de mon outil pour créer un lien (nommé gimp) qui lie l'environnement w64. J'utilise ça pour ma VM Virtualbox qui communique avec mon OS notamment par un dossier partagé. C'est plus simple que d'échanger un zip avec ma VM (ce serait un peu ridicule).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai jamais tenté de compiler sous nux avec Wine et MinGW. Mais sous Windows avec MinGW, c'est aussi d'une lenteur effroyable. Je sais pas ce que le compilo fait, mais il le fait pas vite. :-D
Penses-tu que ton outil va me simplifier la vie ? En particulier, est-ce que ça va compiler a une vitesse normale et en utilisant tous les cœurs ?
Je pense oui. Avec la cross-compilation native (pas Wine ou autre environnement bâtard entre deux-OS pour l'exécution. C'est "natif" dans le sens où ça utilise un compilo fait pour tourner sous nux, seulement il compile à destination d'un autre OS), ça va super vite chez moi (tout aussi vite que la compilation nux pour nux).
Est-ce simple d'utiliser une bibliothèque non présente dans le MinGW de Fedora (j'utilise notamment libclaw) ?
Oui. Il suffit de le configurer, compiler et l'installer avant ton projet, pareil que le projet normal. Il sera installé dans le même préfixe que le reste (les libs installées par Fedora en particulier), et donc quand tu configureras ton projet, il trouvera ces dépendances compilées également.
GIMP master par exemple nécessite babl et GEGL master aussi, qui ne sont pas présents dans Fedora aussi, ainsi qu'une version de cairo supérieure à ce que Fedora propose. J'installe donc ces 3 dépendances supplémentaires avant d'installer GIMP. Ça marche nickel.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai essayé de retrouver vite fait la licence Win 7 sur le site Microsoft après ton message, mais je tombe que sur Windows 8 partout. Je vais dormir là, mais je chercherai demain à nouveau, sauf si quelqu'un trouve avant et poste le lien ici. :-)
En tous cas, j'avais lu la licence de mon OS exact à l'époque, spécifiquement pour savoir cela, et ce point précis était très clairement marqué dedans (vraiment non-ambigu d'après moi, ou alors de manière très fourbe). Je me souviens qu'il y avait un point précis dans le contrat qui dit qu'on peut l'utiliser dans une VM.
En plus comme j'avais pas de CD Windows (comment souvent maintenant dans les portables, qui te vendent avec une sorte de partition cachée qui permet de réinstaller l'OS), j'ai même demandé au vendeur du portable de me le filer, en disant au support que c'était pour l'utiliser en VM, plutôt qu'en OS principal, car autorisé par le contrat. Et ils m'ont filé un iso officiel sans même poser plus de questions.
Donc oui j'en suis sûr, autant que faire se peut quand on n'est pas juriste. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je vais regarder (avec des vrai(e)s utilisat[eur|rice]s que je connais, moi je suis juste un bricoleur) à faire des mockups de cette implémentation de batch, car c'est un sujet qui passionne tout le monde et sa sœur, et tous ont une idée de ce à quoi ça pourrait ressembler (workflow / interface).
Si t'as des mockups, et des idées plus ou moins ("plus", c'est mieux) clairement spécifiés, etc. tu peux participer au GUI brainstorm: http://gimp-brainstorm.blogspot.co.nz/
C'est un peu mort, parce que notre expert UI s'était éloigné de nous, mais il vient de revenir y a juste une semaine. Donc nos retours UI vont s'améliorer.
Tant qu'on y est, ce qui serait super, ce serait de faciliter l'usage de GIMP pour l'animation, avec une "table lumineuse" qui montre les détours des n calques inférieurs, et permet de "jouer" (juste une commande play / pause / accell < > quoi) qui fait "défiler" l'affichage desdits calques) l'anim. En attendant je triche avec les opacités de layer et l'export GIF et ça marche.
Je suis pas certain de comprendre ta comparaison avec une table lumineuse. Veux-tu simplement dire une timeline où on peut spécifier plusieurs calques par frame (et pas comme actuellement, 1 calque = 1 frame)? Si c'est le cas, sois en joie, car c'est en travaux. Je suis depuis quelques mois le mainteneur officiel du plugin core animation-play qui est fourni avec GIMP. Et je suis justement en train de travailler sur ce dont tu parles. Si tu voyais ma version de dév actuelle, tu verrais que ça n'a déjà plus grand chose à voir avec la 2.8. :-)
J'entends également des critiques sur la gestion interactive (une main sur le clavier, l'autre sur la wacom) des brosses, qui ne me posent personnellement aucun problème (mais je ne pains pas avec aussi).
Oui il paraît que GIMP n'a pas les meilleures brosses. Si je pige bien, MyPaint serait vraiment sympa pour créer des brosses (cad que l'UI serait plus aisée à manipuler). Par contre je crois qu'elles sont plus limitées (les brosses sont toutes formées de cercles comme forme de base, ou un truc du genre). Krita aurait les meilleures brosses à ce qu'on dit. Dans tous les cas, on dit que MyPaint et Krita sont tous deux spécifiquement dédiés aux peintres (c'est comme cela que ces deux projets se présentent). GIMP se veut plus générique. Il fait de tout: du croquis au traitement photo en passant par la peinture. Depuis les derniers Libre Graphics Meeting, les 3 projets GIMP, Krita et MyPaint essaient en fait de collaborer pour partager leurs pinceaux (ou du moins pour que chacun soit capable d'utiliser les pinceaux des 2 autres). Bon je suis pas sûr que le projet avance énormément, mais les bases de la discussion sont posées.
Ensuite pas mal de gens dessinent quand même des trucs très cools avec GIMP et la dessinatrice avec qui je travaille semble apprécier créer des brosses et des dynamiques dans GIMP. Un peu d'auto pub: mon webcomic sur la vie d'une Marmotte aventureuse. Y a pas beaucoup de mises à jour parce qu'on revoit pas mal de trucs en cours de route, mais ça devrait prendre le rythme au bout d'un moment. :-)
l'Amiga (où on avait une chaîne de traitement bitmap hors-pair, de Deluxe Paint et Brillance pour l'anim, à ADPro pour le batch, en passant par TVPaint (mais il fallait une carte graphique) ImageFX et PhotoGenics et je parle même pas de la 3D…
Oui j'entends pas mal parler des supers progs de dessin de l'amiga. Moi à l'époque, mon grand frère a eu un amiga pendant environ 2 ans et on faisait que jouer dessus avant qu'on grille l'alim (oui l'alim, c'est rien, mais nous on y pigeait que dalle et mes parents sont danseurs, ils y pigent encore moins), puis on a pas eu d'ordi pendant pas mal d'années. Je suis loin d'avoir eu une jeunesse de geek, je me demande comment j'ai tourné ainsi! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je m'explique: si vous faites un texte et que vous voulez ajouter une ombre et une rotation, rien de plus facile. > Maintenant, si je veux modifier le texte parce qu'il y a une erreur, je dois me retaper à la main la liste des effets que je lui ai mis… Et sincèrement quand on modifie régulièrement une même image, c'est vraiment ULTRA relou !
Tandis que sous photoshop, le calque original et chaque effet reste entièrement éditable après coup !
C'est ce que j'appelle plus haut l'édition non-destructrice avec les calques d'effets. C'est prévu. C'est peut-être même une des conséquences majeures qu'apportera GEGL. Par contre les chances d'avoir ça pour GIMP 2.10 sont très faibles, car bien que le port GEGL sera alors complet, il n'y aura pas l'UI pour en tirer profit. À moins qu'on ait plus de dév d'ici là, par exemple.
Les actions, aussi
Clairement c'est un des autres gros points manquants. C'est aussi une fonctionnalité qui je pense demandera beaucoup de réflexion et de temps pour la faire bien (on peut la développer à-peu-près relativement rapidement, mais on aime le beau code).
mais là en l'état il n'y a pas de gestion par lots "batch" à proprement parler - heureusement qu'il y a imagemagick
En effet à l'heure actuelle, même s'il y a un mode console pour GIMP (on peut même compiler que le mode console de GIMP, sans UI donc sans dépendance à X si on veut. Pour un serveur par ex), c'est pas l'extase. Je pense même qu'aucun des dévs ne considère cela comme une fonctionnalité majeure de GIMP. ImageMagick est clairement beaucoup plus efficace car fait pour.
Quand des utilisateurs nous parlent de cas d'usage qui est clairement un travail à la chaîne (donc du batch) et se plaint que GIMP est pas efficace pour cela, on leur dit à chaque fois d'aller essayer ImageMagick, clairement adapté à l'usage.
Peut-être qu'un jour, quand on aura plus de dévs, en particulier des dévs qui s'intéressent à ce mode et ces usages, et leur donne un peu d'amour, GIMP y sera bon aussi. Mais pour l'instant, je pense qu'il faut accepter ce fait, ou alors retrousser ses manches et nous aider. ;-)
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 ]
[^] # 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é à 2.
Peut-être. Ça y ressemble en tous cas. Tu peux essayer de modifier les headers dont parle le gars en rajoutant ce #if. Si ça règle le problème, c'est probablement le même.
J'avais vu ce rapport de bug en effet, mais j'en avais créé un autre car j'avais aussi d'autres erreurs (comme je dis dans mon rapport) et je dois pas toucher que la lib crt mais une autre aussi. Mais peut-être que les autres erreurs étaient seulement des conséquences du premier et que si on rajoute ce #if, ça corrige toutes les erreurs?
Je ne sais pas. J'ai pas regardé dans le code. :-)
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é à 5.
Salut,
Les dépendances pré-compilées sont fournies par le projet Fedora. Je me sers juste dans leur repo, décompresse et installe dans un répertoire que je crée et dont je me sers comme préfixe.
Pour installer ta propre lib (perso, ou non disponible dans les dépendances pré-comp), tu la compiles et l'installes avec crossroad (crossroad configure && make && make install), tout simplement. Cela l'installera dans le même préfixe que tout le reste [*], mélangé avec les libs pré-compilées et ton projet final. Comme l'environnement est normalement bien configuré, le projet qui nécessite cette lib la verra lors de l'étape de configuration. En gros tu devrais retrouver exactement la même expérience que lorsque tu compiles ton projet et ses libs pour Linux.
Le plus simple est d'essayer, et tu verras, ça vient naturellement pour qui compile régulièrement (ça n'apprend pas magiquement la logique de compilation à ceux qui comprennent pas ce qui se passe quand ils font un ./configure, make et make install, bien sûr).
À propos, c'est pas que C et C++ théoriquement. Ma distrib fournit aussi des paquets nommés gnat-mingw-w64-x86-64, mingw-ocaml, gobjc++-mingw-w64-x86-64, et gfortran-mingw-w64-x86-64. J'en déduis qu'on devrait être capable de cross-compiler aussi en Ada, Objective C++, Objective Caml et Fortran. Et en fait j'ai déjà ajouté le code nécessaire dans
crossroad. Donc si tu installes les dépendances adéquates, tu devrais pouvoir compiler une tripotée de projets différents.Cela étant dit, je dis "théoriquement", car je n'ai compilé que des projets C et C++ moi-même avec crossroad. Je n'ai jamais testé les autres langages en cross-comp, donc j'ai peut-être (probablement même!) loupé des trucs pour que ça marche (des variables d'environnement déjà très probablement, etc.).
Néanmoins j'invite à tester quiconque en a besoin et je me ferai un plaisir de corriger crossroad quand je recevrai des rapports de bug pour d'autres langages (si possible avec des infos sur ce qui manque si vous le savez déjà).
[*]
crossroadne fait pas du multi-préfixe car le but n'est nullement de reproduire un arbre complexe de préfixes dans ton Windows. Ça fait un unique préfixe et tout est dedans.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é à 4.
Salut,
Bien trouvé. C'est pourquoi on devrait toujours réinitialiser son environnement de travail (cache, fichiers de config, etc.) pour tester convenablement un nouvel outil! :p Comme j'avais ce rép depuis longtemps, j'ai dû introduire un bug et ai oublié de tout détruire pour avoir un environnement vierge, comme un nouvel utilisateur. Merci pour le rapport. Corrigé et poussé maintenant. Je ferai une release mineure bientôt.
Oui j'ai eu exactement la même. C'est un bug de mingw. Simplement des fonctions a priori oubliées dans les libs. Donc ça compile, mais ça foire au link.
T'utilises quelle version de MinGW-w64? J'avais eu ce problème avec le dernier build nocturne automatique. J'ai même fait un bug report: https://sourceforge.net/p/mingw-w64/bugs/350/
Tu peux voir exactement le même bug que toi dans le config.log que j'ai attaché au ticket.
Comme j'avais aussi d'autres bugs de macros non définis dans des headers sur le MinGW-w64 stable plus vieux fourni par ma distro, j'utilise actuellement une sorte de mix immonde. J'utilise le build nocturne dans lequel j'ai remplacé les binaires libmingw32.a, libmingwex.a et crt2.o depuis le vieux build stable de ma distro (2.22.90.20120919-0ubuntu1+2).
Ça marche nickel. Je conseille donc de faire ainsi en attendant le fix.
N'hésite pas à reporter que t'as eu la même erreur dans le bug report. :-) Peut-être que cela poussera le bug dans les priorités si on est plusieurs à le rapporter.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: !
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal "Gâteau aux Pommes et Thé à la Cannelle", GIMP inside. Évalué à 8.
Salut,
Merci pour elle pour tous les commentaires. C'est une vraie composition, avec une vraie tarte, assiettes, tasse, etc. qu'elle a placés dans cette position spécifiquement pour ce dessin. Mais oui elle a aussi fait une photo car elle dessine sur l'ordi, un portable avec un gros écran et sa grande tablette graphique, donc c'est assez dur de rester constamment dans un bon angle de vision de l'original. C'est à la fois un des inconvénients (l'encombrement) et des avantages (on peut trimbaler une représentation photographique) du numérique.
Par contre elle ne dessine pas par dessus la photo. Elle est partie d'un canvas blanc et a dessiné dessus avec une brosse numérique le moindre pixel. La photo ne servait que de référence de comparaison.
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é à 3.
Cool, tiens moi au courant si tu essaies crossroad. Tout retour d'utilisation est bienvenu.
En tous les cas, pour les projets un peu gros, je pense qu'il vaut mieux régulièrement au moins compiler dans d'autres OS dès le début (même si on ne teste et que le port est pas pour l'immédiat. Ça ne coûte pas grand chose — avec un tel outil — au minimum de juste cross-compiler et voir que ça le fait sans erreur). À mon avis, même en faisant attention, le diable est dans les détails comme on dit. Mais bien sûr, les corrections seront bien plus simples et minimes si tu as essayé d'être portable dès le début. Et peut-être même qu'il n'en aura aucune, qui sait?!
Merci pour la faute de voc. Il semblerait que tu aies raison. Ces dernières années, j'ai parlé plus souvent anglais ou japonais que français. Forcément ça joue des tours. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Du côté de Gentoo…
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.
Ça a l'air cool. J'aime et ai toujours aimé Gentoo, c'est ma distribution préférée pour et la plus agréable à l'utilisation… hormis pour le temps qu'on y passe! C'est d'ailleurs la seule raison pour laquelle je ne l'utilise plus sur ma machine principale. Je veux plus passer des heures à compiler.
Ceci dit, le problème majeur de
crossdev, c'est que c'est encore un outil de distribution = pour cette distribution seulement. C'est cool pour les utilisateurs de la distrib, mais chiant pour les autres.crossroadse veut générique. Je l'ai commencé sur ma Mageia 3, puis le continue sur ma Linux Mint. Et je veux pouvoir cross-compiler aisément quelque soit ma prochaine distrib, si je venais à changer encore.Fedora (et Suse bien sûr par conséquent!) aussi ont des outils facilitant la cross-compilation, avec un wrapper de ./configure aussi, je crois (si je me souviens bien, j'avais regardé un tuto y a longtemps, mais n'ai jamais testé car j'ai pas de Fedora/Suse justement). C'est pareil. C'est du spécifique à une distrib, donc inintéressant pour moi.
Apparemment
crossdevest intégré à portage et permet donc de compiler l'ensemble de l'arbre de dépendances de Gentoo dans n'importe quel plateforme cible fournie par Gentoo. C'est vraiment cool. Ça permet définitivement plus de choses quecrossroadpuisque je fais que du Windows sur x86 32 et 64-bit pour le moment. Et ma liste de dépendances est limitée à ce que le projet Fedora veut bien pré-compiler, ce qui est forcément moins que l'ensemble des paquetages de Gentoo. Mais c'est bien le principe de Gentoo où on compile déjà tout de toutes façons. Ben là on peut compiler tout à nouveau, mais simplement pour une autre plateforme. :-)Mais bien sûr cela marche ainsi parce que c'est intimement lié à portage, donc à Gentoo. Et cela reste un système de cross-compilation que je ne pourrai pas essayer de sitôt.
Et puis j'espère bien élargir bientôt le champs des possibilités de
crossroadpour compiler vers d'autres plateformes!Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: le troll du copyright
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.
Moi j'ai toujours entendu dire que ça dépendait du pays. D'ailleurs les sites web qui diffusent du domaine public ont en général toujours un avertissement disant que le domaine public est connu pour un pays X (en général le pays du projet), et vous demandant de vérifier les lois du copyright dans votre pays — si différent — pour être sûr de pas enfreindre la loi.
Ceci dit, je viens de regarder Copyright sur Wikipedia. Ça dit ça:
Donc tu as raison pour dire qu'il y a un accord international (sur 166 pays apparemment), mais comme toujours avec les lois internationales, les lois nationales prévalent. Or les pays légifèrent souvent des durées plus longues (jamais plus courtes, semblerait-il!).
Ben moi j'en suis vraiment pas heureux, mais la loi que tu citais est justement la contradiction. Tu l'avais donc apportée toi-même! D'ailleurs c'est pour cela que les gens l'appellent du sobriquet "Mickey Mouse Protection Act", puisqu'elle est le résultat des coups de pouce de Disney vers le gouvernement pour justement que Mickey ne passe pas dans le domaine public.
En gros si je comprends bien cet acte d'extension déjà prolonge les droits d'auteur à 70 ans par défaut. Puis fait un cas spécial pour les œuvres d'entreprise (comme Mickey!) qui passent soit à 95 ans après publication ou 120 ans après création (le plus long est choisi!). Donc malheureusement Mickey est loin d'être dans le domaine public, du moins pas pour ceux qui habitent aux US.
Pour en savoir plus, va lire l'article que tu pointes sur Wikipedia. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Licence Windows 7
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é à 7.
Bon j'ai fait une petite recherche avant d'aller au lit, parce que ça me faisait chier de reporter au lendemain.
J'arrive pas à retrouver le contrat (je pense qu'il est peut-être quelque part dans mon ordi), et tous les liens sur le net que je trouve et qui menaient à un lien Windows 7 sont morts et redirigent vers des pages génériques Windows 8 (bravo Microsoft pour les liens pérennes!).
Par contre j'ai trouvé cette page de answer.microsoft.com qui cite ce qui semble être exactement le paragraphe que j'avais en tête, et pour exactement mon OS (Windows 7 Home Premium OEM): http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_install/am-i-allow-to-install-the-oem-version-of-windows-7/7bcab9e6-f886-4af9-b96f-35a2e5840642
Donc oui on a bien le droit (bien sûr ça s'applique parce que je n'utilise pas mon Win sur la plateforme matérielle, où j'ai un Linux).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: À propos du nom
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.
La légende concerne les deux personnages. Comme tu le dis toi-même, Robert Johnson a une autre chanson où le diable est cité explicitement: "Me and the Devil Blues".
Quant à "Cross Road Blues", même si le diable n'est pas explicitement nommé, toutes les interprétations convergent vers l'histoire de la rencontre avec le diable. Et les paroles sont tout de même assez perturbantes dans ce sens. Ça parle du fait qu'il est à la croisée des chemins et fait du stop, mais personne le prend en stop. Pendant ce temps, la nuit se met à tomber, et il a vraiment peur. À la fin il dit "I believe I'm sinking down", ce qu'on peut comprendre par le fait qu'il croit être perdu. Peut-être parce qu'il est trop tard pour lui, trop tard pour sauver son âme?
Dans tous les cas, je vois pas pourquoi le fait qu'il y ait aussi des histoires sur Tommy Johnson, cela interdirait aussi celles sur Robert Johnson. A priori des historiens pensent que l'un comme l'autre aimaient à entretenir eux-même ces légendes. C'était un bon marketing déjà, en tant que bluesmen. Aussi ils étaient l'un comme l'autre assez connus pour être plutôt roublard. Certaines interprétations du caractère de Robert Johnson laissent penser qu'il pensait que ça le protégeait ainsi que les gens puissent penser qu'il ait un lien avec le diable. Car si on a peur de lui comme associé du diable, oserait-on s'en prendre à lui (probablement oui, car on pense que sa mort pourrait être dû à un mari jaloux, qui n'aurait donc pas eu suffisamment peur de la légende!)?
Dans tous les cas, une chose est sûre: de nos jours, la légende du pacte avec le diable concerne ces deux personnages. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comparatif
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.
Je connaissais pas MXE. Mais je viens de jeter un œil.
Déjà MXE maintient sa propre liste de paquetage de dépendances. D'une, ça doit être un travail de dingue de les garder à jour et vérifier que chacun compile proprement à chaque nouvelle version; de deux, je suis persuadé qu'il n'est pas à jour sur plein de paquetages à cause du premier point (sauf si l'équipe est vraiment grosse?); de trois, même si l'installation des dépendances reste simplifiée certes par rapport à tout faire à la main, il n'empêche que tu te tapes des dizaines de compilations pour un gros projet.
Quand je compile GIMP par exemple, j'ai pas compté, mais avec les dépendances de dépendances, je pense qu'y a bien une vingtaine au moins de paquets installés. Ben ça se fait en genre une minute. C'est du pré-compilé. Donc c'est rapide, et surtout ça marche tout le temps. Le seul cas où une installation de dépendance foire avec crossroad, c'est si les serveurs Fedora sont down. :-)
MXE, ils compilent tout sur l'ordi de build. Donc c'est lent, et ça peut foirer (car on sait tous que les compilations, c'est pas parce que ça marche bien chez le dév que ça marche chez vous (même si c'est normalement le but recherché). Y a beaucoup plus de paramètres en compte.
Et surtout je ne me charge pas de cette liste de dépendances! Donc j'en ai genre probablement bien plus que MXE sans rien avoir à faire. Crossroad va simplement télécharger la liste des paquets Fedora dès que tu l'invoques et est donc toujours à jour par rapport à la dite liste.
Voici donc la liste complète des dépendances de Crossroad: http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_12.3/noarch/
MXE a ça apparemment: https://github.com/mxe/mxe/tree/master/src
C'est pas mal aussi, et j'ai pas compté précisément pour voir qui a la plus grosse. Mais je préfère de loin ne pas avoir à me préoccuper de cela.
Pareil j'ai l'impression que MXE va jusqu'à lui-même compiler MinGW ou MinGW-w64. Franchement toutes les grosses distrib ont MinGW/MinGW-w64 d'installable pour ton OS. Et si vraiment tu veux une version plus récente, y a des builds nocturnes officiels aussi (en tous cas pour MinGW-w64). Vraiment pourquoi s'embêter à compiler ça?
Tout comme les dépendances, je préfère de loin déléguer.
Pour le reste, si tu regardes le tuto de MXE, ça aide pas beaucoup plus que cela. J'ai l'impression que son point principal, c'est de proposer des Makefile pour diverses dépendances.
Mais ils te demandent toujours de modifier tes variables d'environnement et de taper les configure et cmake à rallonge. C'était justement la partie chiante que je suis content d'avoir automatisé. Après tout, c'est toujours les mêmes options. Pourquoi me faire chier à les taper ou copier-coller à chaque fois plutôt que les automatiser dans un script?
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é à 2.
Mon outil configure le projet pour s'installer dans un préfixe donné, ainsi que toutes les dépendances pré-compilées (car on veut pas mélanger des binaires Win avec son OS). Dans la pratique, ça rajoute simplement un --prefix automatique à ton ./configure pour qu'on ait pas à y penser à chaque fois.
Ce
crossroad --symlinkest juste un petit raccourci de mon outil pour créer un lien (nommégimp) qui lie l'environnementw64. J'utilise ça pour ma VM Virtualbox qui communique avec mon OS notamment par un dossier partagé. C'est plus simple que d'échanger un zip avec ma VM (ce serait un peu ridicule).Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Par rapport à une compilation via Wine
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,
J'ai jamais tenté de compiler sous nux avec Wine et MinGW. Mais sous Windows avec MinGW, c'est aussi d'une lenteur effroyable. Je sais pas ce que le compilo fait, mais il le fait pas vite. :-D
Je pense oui. Avec la cross-compilation native (pas Wine ou autre environnement bâtard entre deux-OS pour l'exécution. C'est "natif" dans le sens où ça utilise un compilo fait pour tourner sous nux, seulement il compile à destination d'un autre OS), ça va super vite chez moi (tout aussi vite que la compilation nux pour nux).
Oui. Il suffit de le configurer, compiler et l'installer avant ton projet, pareil que le projet normal. Il sera installé dans le même préfixe que le reste (les libs installées par Fedora en particulier), et donc quand tu configureras ton projet, il trouvera ces dépendances compilées également.
GIMP master par exemple nécessite babl et GEGL master aussi, qui ne sont pas présents dans Fedora aussi, ainsi qu'une version de cairo supérieure à ce que Fedora propose. J'installe donc ces 3 dépendances supplémentaires avant d'installer GIMP. Ça marche nickel.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Licence Windows 7
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,
J'ai essayé de retrouver vite fait la licence Win 7 sur le site Microsoft après ton message, mais je tombe que sur Windows 8 partout. Je vais dormir là, mais je chercherai demain à nouveau, sauf si quelqu'un trouve avant et poste le lien ici. :-)
En tous cas, j'avais lu la licence de mon OS exact à l'époque, spécifiquement pour savoir cela, et ce point précis était très clairement marqué dedans (vraiment non-ambigu d'après moi, ou alors de manière très fourbe). Je me souviens qu'il y avait un point précis dans le contrat qui dit qu'on peut l'utiliser dans une VM.
En plus comme j'avais pas de CD Windows (comment souvent maintenant dans les portables, qui te vendent avec une sorte de partition cachée qui permet de réinstaller l'OS), j'ai même demandé au vendeur du portable de me le filer, en disant au support que c'était pour l'utiliser en VM, plutôt qu'en OS principal, car autorisé par le contrat. Et ils m'ont filé un iso officiel sans même poser plus de questions.
Donc oui j'en suis sûr, autant que faire se peut quand on n'est pas juriste. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Le gros moins de GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 6.
Salut,
Si t'as des mockups, et des idées plus ou moins ("plus", c'est mieux) clairement spécifiés, etc. tu peux participer au GUI brainstorm: http://gimp-brainstorm.blogspot.co.nz/
C'est un peu mort, parce que notre expert UI s'était éloigné de nous, mais il vient de revenir y a juste une semaine. Donc nos retours UI vont s'améliorer.
Je suis pas certain de comprendre ta comparaison avec une table lumineuse. Veux-tu simplement dire une timeline où on peut spécifier plusieurs calques par frame (et pas comme actuellement, 1 calque = 1 frame)? Si c'est le cas, sois en joie, car c'est en travaux. Je suis depuis quelques mois le mainteneur officiel du plugin core animation-play qui est fourni avec GIMP. Et je suis justement en train de travailler sur ce dont tu parles. Si tu voyais ma version de dév actuelle, tu verrais que ça n'a déjà plus grand chose à voir avec la 2.8. :-)
Oui il paraît que GIMP n'a pas les meilleures brosses. Si je pige bien, MyPaint serait vraiment sympa pour créer des brosses (cad que l'UI serait plus aisée à manipuler). Par contre je crois qu'elles sont plus limitées (les brosses sont toutes formées de cercles comme forme de base, ou un truc du genre). Krita aurait les meilleures brosses à ce qu'on dit. Dans tous les cas, on dit que MyPaint et Krita sont tous deux spécifiquement dédiés aux peintres (c'est comme cela que ces deux projets se présentent). GIMP se veut plus générique. Il fait de tout: du croquis au traitement photo en passant par la peinture. Depuis les derniers Libre Graphics Meeting, les 3 projets GIMP, Krita et MyPaint essaient en fait de collaborer pour partager leurs pinceaux (ou du moins pour que chacun soit capable d'utiliser les pinceaux des 2 autres). Bon je suis pas sûr que le projet avance énormément, mais les bases de la discussion sont posées.
Ensuite pas mal de gens dessinent quand même des trucs très cools avec GIMP et la dessinatrice avec qui je travaille semble apprécier créer des brosses et des dynamiques dans GIMP. Un peu d'auto pub: mon webcomic sur la vie d'une Marmotte aventureuse. Y a pas beaucoup de mises à jour parce qu'on revoit pas mal de trucs en cours de route, mais ça devrait prendre le rythme au bout d'un moment. :-)
Oui j'entends pas mal parler des supers progs de dessin de l'amiga. Moi à l'époque, mon grand frère a eu un amiga pendant environ 2 ans et on faisait que jouer dessus avant qu'on grille l'alim (oui l'alim, c'est rien, mais nous on y pigeait que dalle et mes parents sont danseurs, ils y pigent encore moins), puis on a pas eu d'ordi pendant pas mal d'années. Je suis loin d'avoir eu une jeunesse de geek, je me demande comment j'ai tourné ainsi! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Le gros moins de GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 9.
Réponse aux 2 messages précédents:
C'est ce que j'appelle plus haut l'édition non-destructrice avec les calques d'effets. C'est prévu. C'est peut-être même une des conséquences majeures qu'apportera GEGL. Par contre les chances d'avoir ça pour GIMP 2.10 sont très faibles, car bien que le port GEGL sera alors complet, il n'y aura pas l'UI pour en tirer profit. À moins qu'on ait plus de dév d'ici là, par exemple.
Clairement c'est un des autres gros points manquants. C'est aussi une fonctionnalité qui je pense demandera beaucoup de réflexion et de temps pour la faire bien (on peut la développer à-peu-près relativement rapidement, mais on aime le beau code).
En effet à l'heure actuelle, même s'il y a un mode console pour GIMP (on peut même compiler que le mode console de GIMP, sans UI donc sans dépendance à X si on veut. Pour un serveur par ex), c'est pas l'extase. Je pense même qu'aucun des dévs ne considère cela comme une fonctionnalité majeure de GIMP. ImageMagick est clairement beaucoup plus efficace car fait pour.
Quand des utilisateurs nous parlent de cas d'usage qui est clairement un travail à la chaîne (donc du batch) et se plaint que GIMP est pas efficace pour cela, on leur dit à chaque fois d'aller essayer ImageMagick, clairement adapté à l'usage.
Peut-être qu'un jour, quand on aura plus de dévs, en particulier des dévs qui s'intéressent à ce mode et ces usages, et leur donne un peu d'amour, GIMP y sera bon aussi. Mais pour l'instant, je pense qu'il faut accepter ce fait, ou alors retrousser ses manches et nous aider. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]