Je ferai un nouveau poste car il reste quelques points a éclaircir:
-Le chemin ou sont situer les library partagées ne sont pas les mêmes sur les différentes distribution ? Sous Ubuntu elles sont situer dans /usr/lib.
- Et j'ai le même problème avec les manpages /usr/share/man/ sous Ubuntu.
Faire un script d'installation propre: ton conseil d'utilisé make me tente de plus en plus.
D'autant qu'en plus cmake... enfin, cpack, une sorte d'extension à cmake, intégrée par défaut, te permettras de générer des paquets/installateurs.
Je retiens les conseils données et je les appliquerai car la dernière fois que j'ai publier un programme C ont m'a conseiller d'inclure des fichiers d'extension *.c et non *.h ce que j'ai fait ce coup ci et j'ai compris la différence entre les deux.
Je serais curieux de voir l'argument employé. Ok, les .h peuvent servir pour les libs (que ce soit pour les dynamiques ou pour les statiques) mais personnellement, j'ai tendance à m'en servir pour savoir l'API du fichier d'implémentation correspondant. J'y mets aussi les trucs genre "commentaires doxygen", qui expliquent ce que la fonction prend en entrée et génère en sortie (en fait: préconditions, postconditions et invariants, même si le C++ permets déjà de bien l'expliquer via le langage).
Personnellement j'ai mis un an et demie avant d'envisager d'apprendre une GUI en C.
Bof, j'ai appris à utiliser Qt (v3 de mémoire), MFC, wxWidgets par le passé. M'adapter à une nouvelle API ne me prendrais pas longtemps, mais... j'avoue, me fader des IHM c'est ce qui m'emmerde le plus. Je trouve les toolkits assez mal conçus en général, et plus je peux éviter, mieux je me porte. Coup de bol: dans mon taf on me demande quasi pas d'IHM :p
Sinon j'utilise également un simple éditeur et le terminal comme toi. Pas de IDE comme code::block ou autres anjuta...
J'ai utilisé ce genre de trucs, par le passé. J'ai toujours trouvé ça stupide d'avoir, dans un même OS, une palanquée de logiciels implémentant la même fonctionnalité: la gestion de fenêtres. Un jour, j'ai découvert que des WM existaient qui permettent de faire du "docking" avec n'importe quelle application (TWM, dans mon cas i3). Ce jour la, j'ai pris la pente qui à aboutit à la suppression des IDE de ma trousse à outils ;)
[^] # Re: précision des flottants
Posté par freem . En réponse au message Une calculatrice multibases écrit en C avec GTK+3.. Évalué à 2.
D'autant qu'en plus cmake... enfin, cpack, une sorte d'extension à cmake, intégrée par défaut, te permettras de générer des paquets/installateurs.
Je serais curieux de voir l'argument employé. Ok, les .h peuvent servir pour les libs (que ce soit pour les dynamiques ou pour les statiques) mais personnellement, j'ai tendance à m'en servir pour savoir l'API du fichier d'implémentation correspondant. J'y mets aussi les trucs genre "commentaires doxygen", qui expliquent ce que la fonction prend en entrée et génère en sortie (en fait: préconditions, postconditions et invariants, même si le C++ permets déjà de bien l'expliquer via le langage).
Bof, j'ai appris à utiliser Qt (v3 de mémoire), MFC, wxWidgets par le passé. M'adapter à une nouvelle API ne me prendrais pas longtemps, mais... j'avoue, me fader des IHM c'est ce qui m'emmerde le plus. Je trouve les toolkits assez mal conçus en général, et plus je peux éviter, mieux je me porte. Coup de bol: dans mon taf on me demande quasi pas d'IHM :p
J'ai utilisé ce genre de trucs, par le passé. J'ai toujours trouvé ça stupide d'avoir, dans un même OS, une palanquée de logiciels implémentant la même fonctionnalité: la gestion de fenêtres. Un jour, j'ai découvert que des WM existaient qui permettent de faire du "docking" avec n'importe quelle application (TWM, dans mon cas i3). Ce jour la, j'ai pris la pente qui à aboutit à la suppression des IDE de ma trousse à outils ;)