Il faut dire que je suis loin d'être un Guru Linux
Moi non plus. Mais on ne parle pas de linux ici, uniquement de développement.
ne pas bien connaître make cmake
Je suis tombé amoureux de ce truc quand j'ai tenté pour la 1ère fois de compiler openMW. J'avais déjà tenté de compiler pleins de trucs à base d'autotools (genre wxWidgets) et quand ça merde, ça merde juste dur, le code est illisible, et... bref, une plaie.
À côté, j'avais compilé openMW, et j'ai voulu utiliser cpack pour faire un paquet debian, mais le code pour cpack n'était plus à jour. Il ne m'a fallu que 5 minutes à lire un code clair comme de l'eau de source pour corriger (un problème de version de dépendance) et générer le .deb pour ma machine.
C'est tellement simple que c'en est effrayant. Par contre, c'est un générateur de code qui pond un makefile, et comme tous les générateurs de code, ça génère un truc à peu près illisible et clairement pas maintenable.
Maintenant, il permets de compiler en dehors du chemin des sources, sans prise de tête, sous windows comme sous linux ou BSD, et ça, c'est vraiment génial.
J'ai lu que c'était pas terrible quand on essaie de bosser sur de l'embarqué, mais de toute façon je n'ai pas accès à ce type de matos (c'est en projet ceci dit).
Et disons que j'ai un peu déduit ce qu'était une bibliothèque partager de part mes expériences
Pour faire court, une DLL (enfin, .so sous nux, j'ai encore de vieux réflexes, mais il faut dire que j'ai codé et bricolé plus de 6 ans sous windows only...), c'est une liste de fonction qui est chargée en mémoire lorsqu'un programme à besoin d'elle, et qui est partagée quand plusieurs programmes s'en servent.
Donc, gain théorique de ressources...
Sauf qu'en fait, comme dans toutes les optimisations, on ne gagne jamais sur tous les tableaux, et pire: "early optimization is the root of evil".
Pour faire court (et probablement trop simplifié, mais je n'ai que commencé à lire le super doc que j'ai trouvé à ce sujet récemment) le programme indique à l'OS une liste de symboles dont il à besoin pour tourner (sous linux, qui utilise le format binaire ELF, ça s'appelle des DSO).
Ensuite, l'OS va regarder qui les fournit, s'ils sont déjà chargés en mémoire, et en fonction de la situation, charger la DLL. Une fois que cette DLL est chargée, il va effectuer encore du travail pour dire à l'application qui en à besoin où sont les symboles dont elle à besoin.
Ah, et bien sûr, si l'application n'a besoin que d'un nombre limité de symboles, l'OS charge toute la lib quand même...
Je ne parle même pas des risques d'emmerdes liées à l'utilisation des lib dynamiques (dll_hell, modification illégitime de ld_library_path qui détourne ton application, etc).
Alors que pour une lib statique, l'OS charge le binaire, et basta (par contre, quand on fait une maj il faut refaire l'édition des liens).
Après... les deux ont leurs avantages, et il est probable qu'une DLL bien pensée aie plus d'avantages que d'inconvénients. Seulement voila, les gens (et moi le premier jusqu'à il y à peu) ont tendance à partir du principe que ça ne change rien, ou qu' «il suffit de» alors qu'en fait c'est plus compliqué qu'on ne le pense au premier abord.
Je ne suis pas du camp des auteurs de suckless tools, qui ont commencé une distro ou tout est lié en statique nommée stali, je les trouve trop extrêmes (et dans certains documents qu'ils citent il y à de sacrés biais) mais ils ont ma sympathie quand même, parce qu'ils osent penser différemment et agir contre la tendance actuelle de bloater les programmes sous prétexte que "le client rachètera du matos" (phrase entendue d'un de mes profs, ça ma choqué il y à 8 ans, et je suis content que toutes ses prédictions genre .NET vaincra, l'optim sertà rien & co se retrouvent dégommées par le mobile et l'embarqué, les machines les plus communes maintenant :p).
[^] # Re: binaire d'install & économie supposée des lib partagées
Posté par freem . En réponse au message Une bibliothèque partagée (shared object, *.so) pour conversions et calculs mulitbases.. Évalué à 2.
Moi non plus. Mais on ne parle pas de linux ici, uniquement de développement.
Je suis tombé amoureux de ce truc quand j'ai tenté pour la 1ère fois de compiler openMW. J'avais déjà tenté de compiler pleins de trucs à base d'autotools (genre wxWidgets) et quand ça merde, ça merde juste dur, le code est illisible, et... bref, une plaie.
À côté, j'avais compilé openMW, et j'ai voulu utiliser cpack pour faire un paquet debian, mais le code pour cpack n'était plus à jour. Il ne m'a fallu que 5 minutes à lire un code clair comme de l'eau de source pour corriger (un problème de version de dépendance) et générer le .deb pour ma machine.
C'est tellement simple que c'en est effrayant. Par contre, c'est un générateur de code qui pond un makefile, et comme tous les générateurs de code, ça génère un truc à peu près illisible et clairement pas maintenable.
Maintenant, il permets de compiler en dehors du chemin des sources, sans prise de tête, sous windows comme sous linux ou BSD, et ça, c'est vraiment génial.
J'ai lu que c'était pas terrible quand on essaie de bosser sur de l'embarqué, mais de toute façon je n'ai pas accès à ce type de matos (c'est en projet ceci dit).
Pour faire court, une DLL (enfin, .so sous nux, j'ai encore de vieux réflexes, mais il faut dire que j'ai codé et bricolé plus de 6 ans sous windows only...), c'est une liste de fonction qui est chargée en mémoire lorsqu'un programme à besoin d'elle, et qui est partagée quand plusieurs programmes s'en servent.
Donc, gain théorique de ressources...
Sauf qu'en fait, comme dans toutes les optimisations, on ne gagne jamais sur tous les tableaux, et pire: "early optimization is the root of evil".
Pour faire court (et probablement trop simplifié, mais je n'ai que commencé à lire le super doc que j'ai trouvé à ce sujet récemment) le programme indique à l'OS une liste de symboles dont il à besoin pour tourner (sous linux, qui utilise le format binaire ELF, ça s'appelle des DSO).
Ensuite, l'OS va regarder qui les fournit, s'ils sont déjà chargés en mémoire, et en fonction de la situation, charger la DLL. Une fois que cette DLL est chargée, il va effectuer encore du travail pour dire à l'application qui en à besoin où sont les symboles dont elle à besoin.
Ah, et bien sûr, si l'application n'a besoin que d'un nombre limité de symboles, l'OS charge toute la lib quand même...
Je ne parle même pas des risques d'emmerdes liées à l'utilisation des lib dynamiques (dll_hell, modification illégitime de ld_library_path qui détourne ton application, etc).
Alors que pour une lib statique, l'OS charge le binaire, et basta (par contre, quand on fait une maj il faut refaire l'édition des liens).
Après... les deux ont leurs avantages, et il est probable qu'une DLL bien pensée aie plus d'avantages que d'inconvénients. Seulement voila, les gens (et moi le premier jusqu'à il y à peu) ont tendance à partir du principe que ça ne change rien, ou qu' «il suffit de» alors qu'en fait c'est plus compliqué qu'on ne le pense au premier abord.
Je ne suis pas du camp des auteurs de suckless tools, qui ont commencé une distro ou tout est lié en statique nommée stali, je les trouve trop extrêmes (et dans certains documents qu'ils citent il y à de sacrés biais) mais ils ont ma sympathie quand même, parce qu'ils osent penser différemment et agir contre la tendance actuelle de bloater les programmes sous prétexte que "le client rachètera du matos" (phrase entendue d'un de mes profs, ça ma choqué il y à 8 ans, et je suis content que toutes ses prédictions genre .NET vaincra, l'optim sertà rien & co se retrouvent dégommées par le mobile et l'embarqué, les machines les plus communes maintenant :p).