(Courriels de diversion: <labeurs@permutait-indissociable.com> <parcellarise@vainquait-bilan.com> <enrageais@benies-feodale.com> <difficiles@traquenards-delesta.com> <perenniseront@devinerons-indemniseras.com> <degusteront@stylisions-accouplez.com> <ajustions@gercerent-consommerons.com> <reagissant@disquette-majoritaire.com> <polyedres@dechiffrees-divisibilite.com> <fie@speculais-restructurons.com> )
Sylvain Joyeux wrote: >>Ben oui mais non. Donc tu me confirmes que pour utiliser KDevelop >>efficacement, il faut *ne pas* utiliser l'interface graphique pour >>configurer son projet ? > > Je te dis que l'outil graphique ne gere pas ton configure.in. Il gere tes > Makefile.am. D'accord. Il gère tout ce qui est projet : les fichiers à compiler et quoi produire avec. >>On est forcé d'aller taper dans configure.in ou >>configure.in.in ? Donc lequel des deux et quelle est la différence ? Qui >>est généré par KDevelop, qui est produit automatiquement par les >>autotools, qu'est-ce que j'ai le droit de modifier pour expliquer aux >>autotools que je vais compiler avec la clanlib et qu'il faut garder les >>chemins vers les includes et vers les libraries ? > > Ca depend de ce que tu utilises. En gros, si tu utilises aussi les libs KDE > et que tu as un Makefile.cvs (et un repertoire admin/), il faut modifier > configure.in.in. make -f Makefile.cvs produira configure.in a partir de la > et ainsi de suite. Je n'ai pas de Makefile.cvs. Je ne sais plus si j'ai un configure.in.in (ça craint, je te fais chier depuis 3 jours ;-). Mais en gros, la configuration des bibliothèques externes se fait avec le configure.in ou avec le .in.in. On met la même chose dedans en principe, c'est-à-dire du code qui définit des macros CLANLIB_INCS et CLANLIB_LIBS par exemple. Ensuite, j'utilise ces macros au niveau de l'interface graphique ? >>J'avais regardé du côté de Construct et SConstruct, c'est vraiment un >>bonheur. Tu n'as même pas besoin de donner toi-même les dépendances, >>l'outil le fait tout seul. > > ... et tu dois apprendre Python en passant. Accessoirement, je viens d'y > jeter un oeil, il ne remplace pas autoconf, qui est le reel probleme ici. > automake est assez simple a comprendre, mais autoconf ... En fait, si, il remplace autoconf, automake et les macros m4. Mais de manière plus simple. L'idée, si j'ai bien compris, est que tu crée du code Python ou Perl pour configurer et trouver quoi compiler. Tu lui indiques ce que tu souhaite obtenir et il se débrouille tout seul. Et il fonctionne aussi bien sous Unix que sous Windows. Il est capable de trouver seul le bon compilo par défaut, mais tu peux préciser. De toutes façons, l'outil est encore très jeune, mais pour compiler rapidement un petit projet, c'est vraiment du bonheur. Si tu veux vraiment tout maîtriser, il faut se plonger dans la doc et remplacer tous les trucs par défaut, vérifier quels sont les outils dispos et toussa. Et dans ce dernier cas, il faut veille, si tel est ton besoin, à ce que ton fichier fonctionne sur toutes les plateformes de compilation. -- tharibo AT nekeme.net http://www.nekeme.net : Promouvoir le libre ludique "Le temps ne fait rien à l'affaire, quand on est con, on-est-con !" -- Georges Brassens -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>