Le topic de la programmation: Et envoyez des sioux!

**Mayalabielle** · 01/12/2017, 16h41

Je les vois tous, les yeux rivés sur leur écran, Sublime Text, Atom, Visual Studio, tous ces environnements de développement et ces éditeurs de texte à la con.

Ouf, nvim n'est pas dans sa liste.

**Dross** · 01/12/2017, 17h02

Envoyé par William Vaurien

Est-ce que les IA vont remplacer les codeurs ???

Envoyé par William Vaurien

Par-ce que "coder, c'est chiant à mourir" ?

Le mec n'a rien à faire dans l’ingénierie visiblement... S'il est rentré dans la programmation pour faire des maths, c'est dans la recherche qu'il aurai dus s'orienter.

**GrandFather** · 01/12/2017, 19h40

Envoyé par William Vaurien

Persos je pense que les IA qui codent je crois bien que oui, ça va bien finnir par arriver. Plus rapidement qu'on l'imagine. Peut-être pas tout, mais dans les grandes lignes, oui.

La génération automatique de programmes complets, c'est une vieille tarte à la crème de l'I.A. Comment donner des spécifications précises à l'I.A. pour qu'elle génère l'application ? Par du langage naturel ? L'appréhension du langage naturel par l'I.A. est très imparfaite, et les progrès sont extrêmement lents et laborieux en ce domaine. Par un langage formel ? On retrouve alors le principe vieux de quarante ans des systèmes experts, cantonnés à des domaines d'expertise précis. Par un langage formel « universel » ? Je crois que le dessin posté par Dross est assez parlant sur ce à quoi ça ressemblerait...

**William Vaurien** · 01/12/2017, 19h54

On m'aurait parlé de voitures autonomes il y a 20 ans je me serais bien marré...

**GrandFather** · 01/12/2017, 20h19

Envoyé par William Vaurien

On m'aurait parlé de voitures autonomes il y a 20 ans je me serais bien marré...

...et tu aurais eu tort, les premiers prototypes datent de la fin des années 1980 et les essais en trafic réel du milieu des années 1990.

**Dross** · 01/12/2017, 20h19

Envoyé par William Vaurien

On m'aurait parlé de voitures autonomes il y a 20 ans je me serais bien marré...

Pourquoi ? Tout ce qui n'est pas créatif est automatisable, et tout ce qui est créatif ne l'est pas.

Conduire, ce n'est pas créatif, c'est suivre un ensemble de règles. C'est très automatisable.

Coder, y'a une partie non créative (les lourdeurs du langage, etc) ça c'est automatisable/améliorable (comme quand on utilise des templates aujourd'hui en utilisant des raccourcis clavier), et une partie créative (architecture, modélisation, stratégie à utiliser face à une problématique etc) : et ça, ça ne le sera pas.

La seule IA qui en serai capable serai une IA intelligente et consciente, soit une forme de vie numérique très évoluée, si jamais ça arrive, on aura bien d'autres problèmes que de savoir si on sera encore là à coder...

Aujourd'hui quand les gens parlent du "code" il parlent parfois uniquement de "l'utilisation du langage informatique", hors un programmeur quand il "code" il ne fait pas qu'écrire du texte (ça c'est la dernière étape), il pense en terme de concepts, il les organises, il les modélises et à la toute fin, il les écrits. Le truc c'est que pour l'instant on a rien trouvé de mieux que le texte pour transférer ce qu'on a en tête (ce n'est pas limité au domaine de la programmation), alors à moins de révolutionner les interfaces (machine/cerveau), bah... on va continuer d'écrire du code.

**William Vaurien** · 01/12/2017, 21h10

Je pense que tu te trompes: les IA commencent à faire des activités 'créatives', par exemple:
- http://www.numerama.com/pop-culture/...-coldplay.html
- https://sciencepost.fr/2017/11/i-a-a...euse-endormir/
- https://futurism.com/the-worlds-firs...been-unveiled/

Ce n'est que le début, c'est anecdotique, comme l'étaient les voitures autonomes d'il y a 20 ans.

Je ne retrouve pas la source, mais j'avais lu un truc à propos d'une IA qui ré-écrivait des vieux soft en analysant les actions des utilisateurs: en gros elle était capable de recréer une grosse partie de la logique et des processus métiers, de faire une IHM et d'améliorer l'existant...

Bref c'est des balbutiements, je n'affirme rien, mais croire que les dev sont à l'abri est pour moi illusoire. Je suis persuadé que dans quelques années des IA seront capables de fabriquer un prototype d'application à la suite d'une réunion de spécialistes métier.

Et l'informatique 'business' n'est pas très créative au final, elle suit des lois. Les règles métier, l'ergonomie, les protocoles... Même l'architecture peut se créer avec des patterns et peut s'automatiser avec une base de connaissance (et sûrement mieux qu'un humain avec une expérience souvent lacunaire).

**Møgluglu** · 01/12/2017, 21h48

Envoyé par Dross

Le mec n'a rien à faire dans l’ingénierie visiblement... S'il est rentré dans la programmation pour faire des maths, c'est dans la recherche qu'il aurai dus s'orienter.

Les maths qui sont suffisamment complètes et précises pour qu'un ordinateur les comprenne... on appelle ça du code.

**Dross** · 01/12/2017, 22h01

Envoyé par William Vaurien

Je pense que tu te trompes: les IA commencent à faire des activités 'créatives', par exemple:
- http://www.numerama.com/pop-culture/...-coldplay.html
- https://sciencepost.fr/2017/11/i-a-a...euse-endormir/
- https://futurism.com/the-worlds-firs...been-unveiled/

Le cas de l'Art est un peu particulier : car on peux faire de l'art avec le hasard, voir même de l'art sans rien faire (ready-mades).
Heureusement qu'une "IA" y arrive aussi alors.

Envoyé par William Vaurien

Je ne retrouve pas la source, mais j'avais lu un truc à propos d'une IA qui ré-écrivait des vieux soft en analysant les actions des utilisateurs: en gros elle était capable de recréer une grosse partie de la logique et des processus métiers, de faire une IHM et d'améliorer l'existant...

Le machine learning est un très bel outil, mais ça reste un outil dans les mains des programmeurs et limité à des cas particuliers.

Envoyé par William Vaurien

Bref c'est des balbutiements, je n'affirme rien, mais croire que les dev sont à l'abri est pour moi illusoire. Je suis persuadé que dans quelques années des IA seront capables de fabriquer un prototype d'application à la suite d'une réunion de spécialistes métier.

Et l'informatique 'business' n'est pas très créative au final, elle suit des lois. Les règles métier, l'ergonomie, les protocoles... Même l'architecture peut se créer avec des patterns et peut s'automatiser avec une base de connaissance (et sûrement mieux qu'un humain avec une expérience souvent lacunaire).

Elle n'est pas créative mais il faut la transmettre, d'humain à humain (spécialiste/programmeur) c'est déjà pas évident, alors avec une IA... A moins de se limiter à des cas de figures très restreints, comme en parlait GrandFather.
Je pense que l'on va avoir des outils de plus en plus efficaces et puissants, mais tout ces articles sur l'IA/Remplacement du Programmeur c'est presque du troll pour moi, une façon de dire "oui, vous les programmeurs vous allez automatiser 40% des emplois actuels, mais vous n'êtes pas à l’abri pour autant !". Franchement, j'en doute, je pense surtout que le métier va changer considérablement, mais pas disparaitre, à moins d'atteindre la singularité technologique en tout cas.

Edit:

Envoyé par Møgluglu

Les maths qui sont suffisamment complètes et précises pour qu'un ordinateur les comprenne... on appelle ça du code.

Je me suis mal exprimé : si t'aime l’abstraction des maths ça ne garanti pas d'aimer "concevoir et livrer des produits".
Visiblement c'est son cas.

**vectra** · 01/12/2017, 23h12

Tu crées en deux temps trois mouvements un programme qui te génère toutes les combinaisons possibles de bits formant des octets en nombre croissant.
Tu verras: en même pas quelques siècles, le programme va coder Tomb Raider sans aucune intervention humaine ni algo IA. Quand on dit que savoir coder ne sert à rien...

**BentheXIII** · 02/12/2017, 00h10

Y'a-t-il des gens qui utilisent la librairie d'algèbre linéaire Armadillo par ici? J'essaie d'assembler une matrice creuse L (arma::sp_mat) de la manière suivante:

Code:

L = somme_( i = 1: N - 1) ( H_i.T * H_i  )

où H_i est elle même une matrice colonne creuse. Jusqu'à présent je faisais une boucle for sur les indices :

Code:

for i = 0 ; i < N; ++i
L += H_i.T * H_i

J'ai remarqué que la vitesse d'assemblage diminue au fur et à mesure que i augmente. H_i.T * H_i est une matrice creuse comptant un nombre quasi constant d'entrées non nulle pour tout i.
Y'a une subtilité dans l'addition de matrices creuses que j'ai raté?

**William Vaurien** · 02/12/2017, 09h44

Envoyé par Dross

Le cas de l'Art est un peu particulier : car on peux faire de l'art avec le hasard, voir même de l'art sans rien faire (ready-mades).
Heureusement qu'une "IA" y arrive aussi alors.

mais il faut la transmettre, d'humain à humain (spécialiste/programmeur) c'est déjà pas évident, alors avec une IA...

Donc les artistes font tout au hasard et ce n'est pas créatif ??? C'est un peu facile d'évacuer cet argument comme ça. J'ai plutôt l'impression que ces IA qui produisent de la musique ne font pas ça complètement au hasard (et pour le moment c'est pas forcément des réussites artistiques)

Et sinon ici https://futurism.com/first-time-robo...icensing-exam/

Xiaoyi, an AI-powered robot in China, for example, has recently taken the national medical licensing examination and passed, making it the first robot to have done so.
This robot has been designed to capture and analyze patient information.
Now, they’ve proven that Xiaoyi could also have enough medical know-how to be a licensed practitioner.

Donc ce robot a été capable de comprendre les questions d'un examen destiné aux humains. Alors ce n'est sûrement pas une intelligence au sens que nous donnons pour les être vivant, ce n'est 'que' du machine learning et de l'analyse de langage naturel et ce robot ne sera qu'un assistant et pas un vrai docteur.

Mais si on imagine à quoi ces machines ressemblerons dans 20 ans, on peut se poser des questions sur le travail des dev. Et même si l'IA ne remplacera pas tout le monde, elle remplacera bien probablement une grosse partie des équipes actuelles.

**GrandFather** · 02/12/2017, 09h55

Envoyé par William Vaurien

Mais si on imagine à quoi ces machines ressemblerons dans 20 ans, on peut se poser des questions sur le travail des dev. Et même si l'IA ne remplacera pas tout le monde, elle remplacera bien probablement une grosse partie des équipes actuelles.

Si les machines arrivent à se substituer aux développeurs pour générer des logiciels à partir de spécifications ambiguës, bourrées d'implicite et fluctuantes, et de modèles incomplets - notre quotidien en gros -, alors je ne pense pas que les développeurs seront les seuls à craindre pour l'avenir de leur profession... Mais franchement je ne vois pas ça dans un avenir proche. Peut-être dans deux générations...

**William Vaurien** · 02/12/2017, 10h45

Elles feront des logiciels branlants avec des spécs branlantes. Sauf qu'elles les feront en quelques minutes à la place de quelques mois, voir années.
Et les utilisateurs pourront lui dire à loisir : "non, je voudrais plus de rouge et un peu moins de vert, et là je voudrais un carré sans angle droit". Et ils auront un feedback immédiat sans avoir besoin de se prendre la tête avec un ingénieur...
Et oui, je ne vois pas ça arriver tout de suite, encore moins dans les bureaux qui ont déjà au moins 10 ans de retard technologique et 30 ans de dettes techniques.
Mais dans 20 ans nous serons en 2037. Et 2037 ça sonne cyberpunk

; un peu de science fiction pour la route: http://www.quantumrun.com/future-timeline/2037

**Møgluglu** · 02/12/2017, 12h54

Envoyé par Dross

Je me suis mal exprimé : si t'aime l’abstraction des maths ça ne garanti pas d'aimer "concevoir et livrer des produits".
Visiblement c'est son cas.

OK, j'ai pas tout lu, le mec est clairement aigri, et c'est Tchoupi découvre le capitalisme, mais sur le fond il n'a pas tort. Être codeur dans la Silicon Valley, c'est chiant à mourir, oui.
L'environnement est naze, cher, malgré les prix de l'immobilier stratosphériques les infrastructures sont dignes du tiers monde, il n'y a rien d'autre à faire que de bosser, le coût de la vie a chassé toutes les autres activités économiques que l'informatique. La mentalité des boîtes est puante au possible : on ne prend que les meilleurs et on les essore pour en tirer tout ce qu'on peut, si t'es pas assez bon ou corvéable tu dégages. Et si tu aimes concevoir et livrer des produits tu vas être déçu, le gros des développement sont sur des projets à la con sans avenir qu'on a vendu à des investisseurs comme étant le nouveau Google. Le pire est que de temps en temps une de ces startup finit par réussir, et un sociopathe égocentré mégalomaniaque se retrouve à la tête d'une boîte qui "vaut" des milliards.

Bref, ça rend aigri.

Envoyé par GrandFather

Si les machines arrivent à se substituer aux développeurs pour générer des logiciels à partir de spécifications ambiguës, bourrées d'implicite et fluctuantes, et de modèles incomplets - notre quotidien en gros -, alors je ne pense pas que les développeurs seront les seuls à craindre pour l'avenir de leur profession... Mais franchement je ne vois pas ça dans un avenir proche. Peut-être dans deux générations...

L'apprentissage automatique (j'évite le terme IA) est très bon pour identifier des situations connues à partir de données incomplètes. En gros, si un programmeur ailleurs a déjà eu un problème similaire avec le même genre de specs, l'algo d'apprentissage saura appliquer la même stratégie à ton cas. C'est comme le stagiaire qui programme à la souris avec Stackoverflow, quoi.
Par contre, face à une situation jamais vue avant, là ça peut faire vraiment n'importe quoi. (Exactement ce dont on a besoin pour conduire une voiture, quoi.

)

Après c'est le même problème avec les programmeurs humains : le code qui n'est pas testé ne marche pas.

- - - Mise à jour - - -

Envoyé par BentheXIII

Code:

for i = 0 ; i < N; ++i
L += H_i.T * H_i

J'ai remarqué que la vitesse d'assemblage diminue au fur et à mesure que i augmente. H_i.T * H_i est une matrice creuse comptant un nombre quasi constant d'entrées non nulle pour tout i.
Y'a une subtilité dans l'addition de matrices creuses que j'ai raté?

Ta matrice L devient de plus en plus dense au fur et à mesure que tu ajoutes des trucs dedans, donc c'est logique, non ? (Le temps de calcul de L+M est lié au nombre total de coeffs non nuls dans les deux matrices.)

Sinon tu peux casser ta boucle i en deux boucles imbriquées pour faire ta somme par blocs, ou plus généralement évaluer ta somme avec un arbre de réduction, pour accumuler d'abord les matrices les plus creuses entre elles. Même en algèbre linéaire dense, c'est pas plus mal de faire comme ça pour la stabilité numérique. Et en plus c'est parallèle. Ça demande juste un peu plus de mémoire.

**BentheXIII** · 02/12/2017, 15h43

Envoyé par Møgluglu

- - - Mise à jour - - -

Ta matrice L devient de plus en plus dense au fur et à mesure que tu ajoutes des trucs dedans, donc c'est logique, non ? (Le temps de calcul de L+M est lié au nombre total de coeffs non nuls dans les deux matrices.)

Sinon tu peux casser ta boucle i en deux boucles imbriquées pour faire ta somme par blocs, ou plus généralement évaluer ta somme avec un arbre de réduction, pour accumuler d'abord les matrices les plus creuses entre elles. Même en algèbre linéaire dense, c'est pas plus mal de faire comme ça pour la stabilité numérique. Et en plus c'est parallèle. Ça demande juste un peu plus de mémoire.

J'ai réalisé mon erreur 20 minutes plus tard

. Merci pour la suggestion sur les arbres de réduction, je regarderai

**Møgluglu** · 08/12/2017, 19h34

Pour être raccord avec le titre du topic et les derniers débats, une série intéressante d'interviews (pour l'instant 4) de stars des langages de programmation :
http://www.cs.cmu.edu/~popl-interviews/index.html

**William Vaurien** · 13/12/2017, 15h31

Je viens chercher l'expertise des vrai experts. Au sujet de comment améliorer un système de build qui me semble bien pourrave.

Le logiciel en C que je maintient a une structure qui me semble assez étrange (par rapport à ma maigre expérience).
En gros il y a une dizaine de modules (1 fourre tout et les autres par business), chacun ayant plusieurs niveau de source: commun, batch et interface utilisateur et il y a un répertoire include par module.

La compilation se fait en plusieurs passes:
D'abord on passe dans tous les modules et on compile le socle commun de chacun dans une grosse librairie statique.
Ensuite les batch sont compilés et génèrent chacun un binaire propre embarquant les libs de communes.
Ensuite les interfaces sont compilés dans des librairies statiques.
Enfin le programme du client est compilé et embarque toute les librairies statiques.

Les sources sont donc rangées dans un répertoire source à 2 niveaux : les modules et pour chacun les couches techniques.
Chaque répertoire contient son propre Makefile, allégrement copié/collé sur les voisins, mais avec parfois de subtils variations histoire de bien faire chier le mainteneur (en l'occurence moi).

Au total ll y a donc 30 Makefiles quasiment tous identique, et le build de l'ensemble consiste à parcourir les répertoires dans un certains ordres et par niveau technique et appeler le make correspondant:
va dans A, va dans socle, make install
va dans B, va dans socle, make install
...
va dans Z, va dans socle, make install
va dans A, va dans batch, make install
...
va dans Z, va dans batch, make install
va dans A, va dans client, make install
...
va dans Z, va dans client, make install

A pour bien se marrer, il faut ajouter que pour pas se faire chier tous les prototypes sont dans un seul méga .h et que tous les makefiles déclarent des includes vers tous les modules.
En gros tout le monde dépend de tout le monde. C'est trop la goleri.
Et les artefacts du build sont générés dans le répertoire des sources ce qui parfois un peu gênant (notamment dans l'IDE).
(Sans compter l'utilisation du préprocesseur Pro*C de chez Oracle (cf post dans le topic des linuxien) qui bouffe les coredump et ajoute 20K lignes au début de chaque fichier source rendant les binaires gros et moche)

Donc question: vers quels système de build je devrais me tourner si je veux moderniser tout ça ?
CMake ? autotools ? garder Makefile ?

Avec make j'ai vu qu'il est possible:
- de faire une sorte de template à incorporer (include) dans les autres (réduction des parties communes)
- de faire appliquer le même make à différents endroit (donc un seul make pour les compiler tous)
- de générer les artefacts de compilation dans un autre répertoire
- qu'il est possible de faire du make récursif, mais j'ai l'impression que c'est pas une bonne idée au vue des articles que j'ai pu voir.

Je ne connais pas trop les autres, CMake à l'air plutôt plébiscité (par exemple c'est le seul supporté dans CLion pour le moment), et je n'ai pas envie de passer des jours à apprendre un truc pour me rendre compte que c'était pas le bon cheval.

Le but c'est de migrer vers un truc plus simple tout en gardant la structure un peu merdique dans un premier temps, afin de simplifier la maintenance.
Ensuite je voudrais bien tenter de rationaliser les includes, faire une lib dynamique avec le socle commun, etc.

Vous feriez quoi ?

**TarteAuxFleurs** · 13/12/2017, 16h26

Envoyé par William Vaurien

Je viens chercher l'expertise des vrai experts. Au sujet de comment améliorer un système de build qui me semble bien pourrave.

Le logiciel en C que je maintient a une structure qui me semble assez étrange (par rapport à ma maigre expérience).
En gros il y a une dizaine de modules (1 fourre tout et les autres par business), chacun ayant plusieurs niveau de source: commun, batch et interface utilisateur et il y a un répertoire include par module.

La compilation se fait en plusieurs passes:
D'abord on passe dans tous les modules et on compile le socle commun de chacun dans une grosse librairie statique.
Ensuite les batch sont compilés et génèrent chacun un binaire propre embarquant les libs de communes.
Ensuite les interfaces sont compilés dans des librairies statiques.
Enfin le programme du client est compilé et embarque toute les librairies statiques.

Les sources sont donc rangées dans un répertoire source à 2 niveaux : les modules et pour chacun les couches techniques.
Chaque répertoire contient son propre Makefile, allégrement copié/collé sur les voisins, mais avec parfois de subtils variations histoire de bien faire chier le mainteneur (en l'occurence moi).

Au total ll y a donc 30 Makefiles quasiment tous identique, et le build de l'ensemble consiste à parcourir les répertoires dans un certains ordres et par niveau technique et appeler le make correspondant:
va dans A, va dans socle, make install
va dans B, va dans socle, make install
...
va dans Z, va dans socle, make install
va dans A, va dans batch, make install
...
va dans Z, va dans batch, make install
va dans A, va dans client, make install
...
va dans Z, va dans client, make install

A pour bien se marrer, il faut ajouter que pour pas se faire chier tous les prototypes sont dans un seul méga .h et que tous les makefiles déclarent des includes vers tous les modules.
En gros tout le monde dépend de tout le monde. C'est trop la goleri.
Et les artefacts du build sont générés dans le répertoire des sources ce qui parfois un peu gênant (notamment dans l'IDE).
(Sans compter l'utilisation du préprocesseur Pro*C de chez Oracle (cf post dans le topic des linuxien) qui bouffe les coredump et ajoute 20K lignes au début de chaque fichier source rendant les binaires gros et moche)

Donc question: vers quels système de build je devrais me tourner si je veux moderniser tout ça ?
CMake ? autotools ? garder Makefile ?

Avec make j'ai vu qu'il est possible:
- de faire une sorte de template à incorporer (include) dans les autres (réduction des parties communes)
- de faire appliquer le même make à différents endroit (donc un seul make pour les compiler tous)
- de générer les artefacts de compilation dans un autre répertoire
- qu'il est possible de faire du make récursif, mais j'ai l'impression que c'est pas une bonne idée au vue des articles que j'ai pu voir.

Je ne connais pas trop les autres, CMake à l'air plutôt plébiscité (par exemple c'est le seul supporté dans CLion pour le moment), et je n'ai pas envie de passer des jours à apprendre un truc pour me rendre compte que c'était pas le bon cheval.

Le but c'est de migrer vers un truc plus simple tout en gardant la structure un peu merdique dans un premier temps, afin de simplifier la maintenance.
Ensuite je voudrais bien tenter de rationaliser les includes, faire une lib dynamique avec le socle commun, etc.

Vous feriez quoi ?

CMake c'est vraiment costaud, mais j'ai trouvé la courbe d'apprentissage assez rude, la doc est pas tip top à mon humble avis. Mais une fois que c'est pris en main, tu fais tout avec !

**rOut** · 13/12/2017, 16h43

Le language est une horreur mais oui, ça fait le boulot de manière portable.

**Cwningen** · 13/12/2017, 17h02

Récemment, j'ai vu des projets C/linux passer des autotools à meson. J'ai jamais utilisé moi-même donc j'ai pas d'avis mais ça a l'air de plaire. Sinon j'aime bien cmake, et j'ai jamais réussi à me mettre aux autotools.

En gros projet avec Makefile, il y a le noyau linux, c'est assez bien fait pour ajouter des modules simplement (même en dehors de l'arbre des sources) mais j'ai jamais regardé comment c'était fait dans le détail.

**William Vaurien** · 13/12/2017, 17h02

c'est pire que make ???

**vectra** · 13/12/2017, 17h09

De mon point de vue, Cmake est juste le standard. C'est d'ailleurs pas un outil très récent (développé par Kitware pour compiler VTK et ITK).
Pas mal de boites d'info le pensent, en tous cas.

C'est pas forcément très difficile d'apprendre CMake par l'exemple. On se retrouve assez vite à génerer des équivalents Makefile avec très peu de lignes de code.

**William Vaurien** · 13/12/2017, 17h21

Alors je vais lire de la doc CMake pendant les vacances de Nowel

ce tuto à l'air sympa et va plus loin que le simple hello world:
http://derekmolloy.ie/hello-world-in...ions-to-cmake/

Et il y en a plein d'autres...

L'avantage c'est que je vais pouvoir commencer par faire une version basée sur les Makefile actuels.

**Møgluglu** · 13/12/2017, 17h29

Oui, CMake est suffisamment standard et maintenu pour être compatible avec la durée de vie de ton projet. Et fuis les autotools : ton système de build actuel est un modèle de clarté, modernité et simplicité en comparaison.

**Raplonu** · 19/12/2017, 10h52

Pour continuer sur les cmake, quelqu'un aurait des ressources (tuto, article, conseil) afin de faire des repos git modulaires ?

Mon idée est de soit donner directement le chemin vers le module désiré avec

Code:

cmake -PATH_TO_XXX=XXX ..

Ou laisser le projet utiliser le FindXXX.cmake ou en dernier recours appeler la commande

Code:

git submodule update module/XXX

L'idée, c'est d'automatiser le tout et de surtout éviter le plus possible l'appelle à git submodule.

Bisous

**rOut** · 19/12/2017, 12h55

Envoyé par Cwningen

Récemment, j'ai vu des projets C/linux passer des autotools à meson. J'ai jamais utilisé moi-même donc j'ai pas d'avis mais ça a l'air de plaire. Sinon j'aime bien cmake, et j'ai jamais réussi à me mettre aux autotools.

En gros projet avec Makefile, il y a le noyau linux, c'est assez bien fait pour ajouter des modules simplement (même en dehors de l'arbre des sources) mais j'ai jamais regardé comment c'était fait dans le détail.

Ouais, ça a l'air d'être à la mode dans les projets de l'univers Unix qui veulent dégager autotools. Mais je n'ai personellement pas compris pourquoi. Le machin est codé en python, fait un peu le même taf que CMake avec moins de portabilité, mais avec encore une syntaxe custom à apprendre.

Encore de la fragmentation de l'écosystème AMHA, sans vraiment de feature déterminante pour le rendre intéressant.

- - - Mise à jour - - -

Envoyé par Raplonu

Pour continuer sur les cmake, quelqu'un aurait des ressources (tuto, article, conseil) afin de faire des repos git modulaires ?

Mon idée est de soit donner directement le chemin vers le module désiré avec

Code:

cmake -PATH_TO_XXX=XXX ..

Ou laisser le projet utiliser le FindXXX.cmake ou en dernier recours appeler la commande

Code:

git submodule update module/XXX

L'idée, c'est d'automatiser le tout et de surtout éviter le plus possible l'appelle à git submodule.

Bisous

J'ai pas tout saisi ce que tu souhaites faire, mais à mon avis la gestion de dépendance peut et même devrait se faire indépendamment du système de build. Les sous-modules git sont un moyen de gérer les dépendances, simplement si toutes les dépendances sont stockées dans des repos git, un peu plus compliqué mais faisable avec des ponts git-remote-xxx sinon. D'autres moyens sont possibles AMHA, même avec des outils qui ne sont pas forcément prévus pour le C++ à la base, genre npm et cie.

(CMake permet de le faire aussi avec des macros ExternalProjects, mais je pense que c'est mieux de ne pas mélanger le build et les dépendances donc pour ma part j'éviterais ça.)

Ensuite la question est "Comment faire le lien entre les dépendances récupérées par le système de gestion de dépendances et le système de build". Pour ça, CMake a un mécanisme d'import de dépendances bien fichu, à base de find_package, avec toute une nomenclature sur le format que doit avoir un "package" CMake pour être reconnu, et une liste de chemins de recherche par défaut.

En gros, un "package" CMake doit avoir un fichier <package>-config.cmake (ou <Package>Config.cmake) à la racine de son répertoire, et être situé dans une liste de répertoire prédéfinis (https://cmake.org/cmake/help/latest/...d:find_package), ou bien à l'endroit indiqué par une variable CMake nommée "<package>_DIR". Le package peut être sous forme de source ou de version précompilée, du moment que les même targets sont définies.

A mon avis, et de mon expérience, c'est suffisamment flexible pour permettre la gestion propre des dépendances, avec un premier outil qui va les installer / cloner / récupérer dans un répertoire prédéfini, et ensuite à base de find_package dans CMake pour importer les targets.

- - - Mise à jour - - -

Ensuite, il y a quelques tentatives pour rendre la création de projets C++ plus simple et plus semblables à ce qu'on trouve dans d'autres langages genre Rust ou D, ou l'arborescence des projets détermine le système de build en utilisant quelques conventions assez courantes :

- https://github.com/berenm/CMakeBuildPackage
- https://github.com/sandstorm-io/ekam
- https://github.com/Dekken/maiken

**Raplonu** · 19/12/2017, 18h36

Bon, j'ai réussi à mettre mes idées à plat…

J'ai plusieurs modules avec des inter-dépendances :

Comme je bosse sur mes différents modules en permanences, j'ai un repo par modules. À l'initialisation, si A utilise B, je fait :

Code:

cd A/build
cmake -DPATH_TO_B=../../B ..

Ou je défini une variable d'environnement…

Mais je veux aussi permettre a un utilisateur de pouvoir cloner tout mon bordel sans gérer mes dépendances. Du coup, 2 options, soit il la possède déjà et elle est trouvé grâce à FindB.cmake soit elle est téléchargée. Pour télécharger, j'utilise DownloadProject qui marche plutôt bien.

Par souci de propreté, la dernière option est désactivée par défaut et nécessite un -DENABLE_DOWNLOAD=TRUE par exemple.

Le tout est de réussir a interfacer une dépendance de la même façon avec add_subdirectory(PATH_TO_B ), find_package(B ) et download_project(PROJ B…).

**Møgluglu** · 22/12/2017, 12h47

Un bug rigolo (contexte : un compilateur de shaders pour GPU) : https://pastebin.com/RLD9eiBv

La morale de l'histoire ? Je ne sais pas trop. Probablement que la confluence, c'est important. Que les calculs en virgule flottante sont et doivent rester déterministes comme le reste. Et que l'opérateur <= devrait s'écrire en un seul caractère, et l'opérateur < en prendre deux, pour que les paresseux choisissent le bon par défaut.

**ducon** · 22/12/2017, 13h19

OK, on remplace <= par ⩽.

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages