Sébastien Wilmet a écrit 713 commentaires

Cool c'est bon à savoir.
Mais alors que reproches-tu à la syntaxe de CMake ?

Pour la syntaxe de CMake le seul truc qui m'ennuie c'est qu'il faut répéter dans le end la même chose que dans le if ou autre, par exemple :

if (blabla)
endif (blabla)

À part ça je trouve que ça va.

http://www.scons.org/wiki/SconsVsOtherBuildTools

Ça confirme bien ce que je dis.

OK.

Mais il me semble que SCons et Waf offrent plus ou moins le même genre de fonctionnalités que CMake, dont notamment le fait de vérifier si la compilation est possible et de paramétrer cette compilation (suivant le système et les choix de l'utilisateur), ce que ne permettent pas directement make ou redo.

Ou CMake.

CMake, et sans doute SCons et Waf aussi (mais je n'en suis pas sûr) ¹, sont des générateurs de Makefile, et donc make est quand même utilisé par après.
Donc ces outils ne se situent pas au niveau de make, mais des autohell autotools.

Si les remplaçants de make commencent à devenir populaire, on pourrait imaginer que CMake et compagnie supportent plusieurs « make-like » en sortie.

¹ Pour moi SCons et Waf sont des alternatives à CMake et aux autotools, pas à make.

Un petit tour sur Web sémantique et on comprend déjà un peu mieux :

« Le Web sémantique désigne un ensemble de technologies visant à rendre le contenu des ressources du World Wide Web accessible et utilisable par les programmes et agents logiciels, grâce à un système de métadonnées formelles, utilisant notamment la famille de langages développés par le W3C[1]. »

« Ce genre de situation met bien en évidence l'importance de ne JAMAIS céder ses droits d'auteur à un organisme centralisateur, même si c'est pour le bien du soft. Une fois le code bourré de patchs d'auteurs différents, le mode de développement peut changer, mais plus la licence. »

C'est une solution dans le cas où il y a beaucoup de contributions, sinon il est facile à l'entreprise de réécrire les quelques bouts de code dont ils ne sont pas propriétaires du copyright.

Aussi, ça peut être embêtant si on a pas spécifié « version un-telle ou supérieure ». Par exemple certaines parties du noyau Linux sont en GPL 2 only, et certains dev ne sont plus joignables, donc impossible de passer à la GPL 3+. Enfin bon de toute façon Linus n'aime pas la GPL v3 (c'est peut-être juste un prétexte pour ne pas devoir réécrire du vieux code que plus personne ne comprend ->[]).

« L'interface simple est claire » s/est/et/

Il aurait été difficile de faire une interface simple et obscure.

On appelle ça le fauxpen source :
http://www.framablog.org/index.php/post/2009/11/12/fauxpen-s(...)

Un autre exemple avec Paint.NET qui était aussi libre et est devenu propriétaire :
http://www.framablog.org/index.php/post/2009/12/20/paint-net(...)

Bien que je n'habite pas trop loin je n'ai pas su venir, mais le sujet m'intéresse beaucoup.
Y aurait-il des slides ou un résumé à disposition ?

Sinon je suppose qu'il y aura une conférence plus ou moins du même type au FOSDEM (du moins j'espère :).

KDE est déjà sorti (et moi aussi du coup).

Hein je pensais que tu disais ça en pensant que certains diraient que de toute façon ce sera comme pour KDE 4.0, c'est à dire qu'il manquera plein de fonctionnalités et que ça ressemblera plus à une version alpha¹, mais qui oserait penser une chose pareille !

¹ et puis que de toute façon Unity cay l'avenir, etc…

Les plus mauvaises langues te diront que tu t'es trompé, c'est 2012 que tu devais choisir dans ce cas-là.

Une chouette fonctionnalité de VMware Workstation qui n'existe pas dans VirtualBox est le glisser/déposer de fichiers entre la machine hôte et la machine invitée. Bon évidemment ça ne fonctionne que si les deux ont une interface graphique.

Avec VirtualBox on sait cependant facilement définir des points de montages pour partager des fichiers entre les deux, ça je pense que c'est plus difficile avec VMware.

En bépo j'utilise énormément le AltGr (pouce droit) + main gauche et ça me va très bien.

C'est le AltGr + main droite qui pose problème avec la plupart des azerty.

>> eh oui en Belgique on a l'énorme chance d'apprendre le néerlandais !
> Puis bon, dans la vie de tous les jours, à une échelle mondiale, c'est quand même plus utile de comprendre l'allemand que le néerlandais...

J'étais ironique en disant que c'était une énorme chance ;) Je suis bien d'accord que ça sert strictement à rien sauf pour ceux qui veulent bosser à Bruxelles, et encore ça dépend dans quel secteur.

Le flamand est quand même un cours obligatoire dans beaucoup d'écoles, dès la primaire.

C'est pas vraiment le même sujet. Les deux (ou plutôt les 4) bouquins que tu cites n'expliquent pas je pense les techniques pour être le plus efficace en programmant et produire du code de meilleure qualité.

Ça dépend des pays, et sans doute aussi des régions…

Quand j'avais cours de néerlandais les « ij » on les prononçait « eille » et pas « aille ». Donc ça doit sans doute venir des différents accents.

(eh oui en Belgique on a l'énorme chance d'apprendre le néerlandais !)

Sur les bonnes pratiques de programmation j'ai acheté le bouquin Code Complete [1], j'ai pas encore tout lu mais je peux dire que c'est un bon bouquin, le seul défaut c'est que c'est édité par Microsoft Press (mais il n'y a pas grand chose à voir avec crosoft dedans).

Bon maintenant il est un peu plus gros que The Pragmatic Programmer (900 pages contre 350).

Les libristes ils lisent quoi d'habitude dans ce sujet ? (bon OK vous allez me répondre : le code d'autres programmes ;)

[1] http://www.amazon.fr/Code-Complete-Steven-C-McConnell/dp/073(...)

J'ai vérifié dans le livre LaTeX: A Document Preparation System (2e édition) de Leslie Lamport. Et il est indiqué à l'annexe E Using Plain TeX Commands :

« Plain TeX's $$ does not work properly; it has been replaced by the LaTeX commands \[ and \]. »

Étant donné que ce livre est la référence, je vais changer ça pour la version 2.0.1 qui pointe bientôt le bout de son nez.

J'ai aussi appris que les commandes \( et \[ sont fragiles (et donc dans certains cas il faut rajouter \protect), tandis que $ … $ ne l'est pas.

Tu dois installer les paquets *-dev correspondants.
Pour gdk-x11 j'ai eu un retour comme quoi c'était gtkview-dev sur Ubuntu, en tout cas sur Fedora c'est libX11-devel.

Oui, cette erreur est classique, je devrais peut-être expliquer plus en détail dans le fichier INSTALL.

En bref, tu dois installer gsettings-desktop-schemas.

LaTeXila utilise GSettings, qui est le successeur de GConf. GSettings est inclus dans GLib 2.26.

gsettings-desktop-schemas est nécessaire à LaTeXila pour savoir quelle est la police à chasse fixe définie pour le système (Monospace 10 par défaut je pense). Fedora 14 par exemple a un paquet qui porte le même nom, je suppose que dans Ubuntu c'est le cas aussi, mais sinon ce n'est vraiment pas compliqué à installer, c'est juste des fichiers xml.

Aussi, pour que GSettings fonctionne (pour que les préférences soient enregistrées quelque part), il faut un backend : dconf.

C'est étonnant, car le livre* que j'ai dit qu'il est préférable d'utiliser $$ … $$ pour des questions de robustesse et de facilité de saisie (il n'est rien dit de plus).

Bon maintenant ce livre n'est pas la référence, et apparemment $$ … $$ n'est pas compatible avec certains package, donc pour la prochaine version ce sera sans doute \[ … \]. J'aimerais quand même une source plus fiable que wikibooks et le lien donné dans la note.

Merci en tout cas pour cette remarque.

* LaTeX par la pratique, O'Reilly (p.86)