Bonjour, hier soir j'ai voulut tester un petit peu de code C++, je suis pas un grand spécialiste et justement je me pose une question.
Voilà, j'ai tenté une compilation d'un code pour tester SDL + OpenGL et là le drame.
pour générer arriver à un truc du genre (il me fallait juste ajouter les lib et include pour SDL quelque part mais je sais pas où...)
g++ -Iinclude -I/usr/include/SDL -I/usr/include/SDL -o bin/monfichier src/monfichier.cpp -Llib -lSDL -lglut
Et bien je cherche encore.
Bref je suis allé voir du coté Eclipse CDT et là bizarrement je n'ai pas eu le moindre mal à configurer mon projet sans le moindre problème.
Bref ok, mon truc c'est plutôt Java ou PHP, mais sortir la grosse artillerie pour vouloir faire quelques petits tests, c'est plutôt décourageant.
Alors, automake et autoconf a certes des avantages pour la distribution de source, mais peut-être que quand on distribue un IDE qui les utilisent, ils faudraient peut-être faire un minimum pour que ça soit utilisable.
Oui je sais les grincheux me diront que si je ne suis pas content, je pourrait toujours développer un truc pour ça, seul hic, je ne comprend absolument pas comment celà marche, je n'en ai pas la nécessité (CDT est mille fois plus simple), c'est juste que le peut de doc qu'on trouve à ce sujet nous explique que c'est complètement imbuvable et la lecture d'un configure.in est complètement imcompréhensible...
Journal On est pas vendredi mais quand même, kdevelop, autoconf automake autoincompréhensible
30
jan.
2007
# Yep
Posté par Snarky . Évalué à 2.
En plus la doc est bien faîtes : http://scons.org/
[^] # Re: Yep
Posté par kolter (site web personnel, Mastodon) . Évalué à 1.
M.
[^] # Re: Yep
Posté par Frédéric COIFFIER . Évalué à 2.
J'avais utilisé SCons et je le trouvais pas trop mal pour des petits projets avec de petits besoins mais lorsqu'il faut détecter tout un tas de choses par rapport à l'environnement, ça devient moins simple.
[^] # Re: Yep
Posté par Olivier Serve (site web personnel) . Évalué à 1.
J'avais commencé par utiliser Scons pour koinkoin. C'est sympa pour des projets indépendants, mais c'est finalement lourd pour gérer les versions des bibliothèques, les répertoires d'install...
Depuis j'utilise le système standard de build de kde basé sur les autotools (kde3 only pour le moment). C'est finalement plus simple que Scons. Et je passerai à CMake pour KDE4.
# Tout pareil
Posté par alberthier (site web personnel) . Évalué à 3.
Même si je trouve ces outils très puissants : vérif que les dépendances sont là, etc... Je n'ai jamais réussi à comprendre plus que l'ajout d'un fichier dans un projet existant.
Pour moi c'est une usine à gaz (volontairement?) obscure qui ont en plus le bon gout d'avoir des versions incompatibles entre elles (pas de rétro-compatibilité)
Pour l'instant QMake m'a toujours suffit et il a l'immense avantage d'être très simple.
Quand je développe, ben je veux développer, pas passer des heures à chercher à comprendre comment fonctionnent les outils qui sont supposés aider la compilation.
Comme dit plus haut, tu trouvera sans doute ton bonheur ailleurs : qmake, cmake, scons, jam, et...
PS : KDevelop peut utiliser des fichiers projets QMake.
[^] # Re: Tout pareil
Posté par Anonyme . Évalué à 2.
1) Je n'ai jamais trouvé un seul tutorial/doc clair et préci
2) Soit les gens prennent ca pour acquis, soient ils disent que c'est de la merde car trop complexe.
Ma conclusion est donc la suivante :
- du point 1) j'en tire la conclusion qu'il n'y a effictevement aucune façon simple et claire d'expliquer le fonctionnement des autotools, point qui corrobore leur obscurité pour le néophite.
- Mais le point 2) tend a montrer que ceux qui ont sérieusement mis les mains dans le camboui ont compris le secret-qui-n'est-pas-facile-a-expliquer, et que maintenant ils vivent dans la lumière et le bonheur. Les autres n'ont passé le cap pour comprendre le truc.
En tout cas, j'aimerais bien maîtriser les autotools, ca a l'air très puissant et pratique.
(en croisant les doigts pour qu'il n'y ait pas de gourou du autotools qui passe pour dire "non, non, en fait c'est réellement trop complexe".)
[^] # Re: Tout pareil
Posté par Vincent LE LIGEOUR . Évalué à 1.
moi je me suis mis aux autotools depuis quelques jours, et en fait bien expliqué sur un exemple très simple ben ca marche.
En gros dans le configure.in c'est une succession de macros (sans doute shell) qui permettent de générer le gros script shell configure.
Les Makefile.am ensuite on mets les sources que l'on veut dans des variables avec des noms predefinis.
Pour un exemple simple regardez par la : http://ultrastar-ng.cvs.sourceforge.net/ultrastar-ng/UltraSt(...) (attention pub inside :) )
Vincent
[^] # Re: Tout pareil
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Je crois que c'est du M4.
[^] # Re: Tout pareil
Posté par Troy McClure (site web personnel) . Évalué à 5.
[^] # Re: Tout pareil
Posté par Troy McClure (site web personnel) . Évalué à 3.
J'ai mis les mains dans le cambouis, à plusieurs reprises, j'ai même utilisé libtool c'est dire. J'ai appris m4. Et maintenant je vis dans la peur et l'obscurité.
Les autotools ça n'est ni puissant ni pratique (ni vraiment portable en dehors de linux..)
[^] # Re: Tout pareil
Posté par imalip . Évalué à 2.
Si, les autotools sont portables en-dehors de Linux. Le probleme, c'est qu'il faut que le projet qui les utilise le soit aussi.
[^] # Re: Tout pareil
Posté par Troy McClure (site web personnel) . Évalué à 3.
Ou alors il faut dire que ça n'est portable que si on utilise les outils/compilo gnu, à ce moment là d'accord.
[^] # Re: Tout pareil
Posté par rewind (Mastodon) . Évalué à 2.
ça part de petits problèmes simples et ça va crescendo...
[^] # Re: Tout pareil
Posté par Olivier Serve (site web personnel) . Évalué à 1.
# Solution
Posté par Florent Bayle (site web personnel) . Évalué à 5.
Lancement de kdevelop. Projet > Nouveau projet.
Je choisis C++ > KDE > Simple application KDE basée sur Designer. Je met le projet (appelé test) dans /tmp. Suivant, suivant, suivant, terminer.
Tiens, un onglet "configurer automake" à droite, cliquons dessus. Une petite icône avec un espèce de clef dessus nommée "options", cliquons aussi.
Un petit tour dans l'onglet "Bibliothèques", et là, ho miracle, je peux ajouter des bibliothèques, comme "-lm" (le -l est déjà présent dans la boite de dialogue)... Pour les "-L", il y a dans le premier onglet un truc nommé "drapeaux de l'éditeur de liens (LDFLAGS)".
Il m'a fallut quoi... 3 minutes pour faire tout ça, alors que j'avais jamais utilisé kdevelop.
[^] # Re: Solution
Posté par Vincent LE LIGEOUR . Évalué à 1.
`sdl-config --libs` par exemple ou `pkg-config --libs cairo`
[^] # Re: Solution
Posté par Frédéric COIFFIER . Évalué à 2.
Mais je fais comme toi, car je n'ai jamais compris les autotools... et quand on veut distribuer un code, c'est pas simple...
[^] # Re: Solution
Posté par fleny68 . Évalué à 2.
Sinon on peut utiliser AC_ARG_MACHIN pour permettre de mettre le path de sdl-config en option à configure, ou shunter le test si SDL_CFLAGS et SDL_LIBS sont positionnés. Je crois me rappeler que le configure.in de GCompris utilise un truc comme ça pour la xcompil.
[^] # Re: Solution
Posté par fleny68 . Évalué à 0.
On es installe? Parce que bon, pour développer, il faut quand meme avoir l'environnement de dev. Si tu as pas le compilateur...
Et si SDL est une dépendance optionnelle ?
On met des AC_ARG_ENABLE dans le configure.in, c'est là pour ça.
Et comment on choisit là où il faut installer l'application dans un Makefile traditionnel ?
UUn makefile traditionnel? ça veut rien dire. Pour moi le traditionnel c'est celui généré par autoconf.automake, et il y a le --prefix qui est là pour ça. Sinon ça dépend de l'auteur, faut lire la doc.
[^] # Re: Solution
Posté par Frédéric COIFFIER . Évalué à 5.
[^] # Re: Solution
Posté par kolter (site web personnel, Mastodon) . Évalué à 4.
M.
[^] # Re: Solution
Posté par Pipo2 . Évalué à 1.
Pire, avant j'accédait à www.kdevelop.org par Tor, mais on dirait que maintenant ils ont blacklisté aussi les oignons Tor. Les choses se compliquent.
# autoproject?
Posté par fleny68 . Évalué à 2.
autoproject interviews the user, then creates a source package for a
new program which follows the GNU programming standards. The new
package uses autoconf to configure itself, and automake to create the
Makefile. `make distcheck' succeeds.
The idea is that you execute autoproject just once when you start a
new project. It will ask a few questions, then create a new directory
and populate it with standard files, customized for the new project.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.