Discussion :

[VBurel]

La question prend le problème par le mauvais bout.

La portabilité n'est pas une question. Je parle de la capacité de gérer des projets avec des sources éparpillés sur des disques locaux ou réseaux (possiblement utilisé dans d'autres projets sur d'autre plateforme) et avoir un projet de compilation comme on a sur tout IDE Visual ou XCode, et ca a commencé avec Borland C++ et Visual en 1995 ou par là.

Le but c’est qu'on puisse éditer les sources du projet, compiler en mode debug et release, et puis tracer (avec des watch et des dump) c'est a peu près tout ce qu'il faut. Eclipse pourrait le faire, mais il manque la gestion de projet. Alors quel IDE gère les projets sous Linux ?

[floyer]

Sous Linux, les produits sont sous formes d’une arborescence avec un fichier Makefile maître qui fait tout (ou une variante) quitte à appeler des Makefile subordonnés. Pour des projets compliqués où il existe des dépendances d’autres projets, la démarche est typiquement de packager chaque bibliothèque avec le gestionnaire de package propre à la distribution. Cela permet des installations automatiques. Il peut y avoir Vcpkg et Conan qui permettent de gérer l’installation de bibliothèques de façon portable (mais je n’ai pas testé) comme le font pip pour Python, npm pour JS, etc. Il est question de bibliothèques extérieures au projet comme Qt, un compresseur ZIP ou autre qui n’est pas inclut dans le projet.

Je ne pense pas que VC6 aille chercher automatiquement des dépendances sur Vcpkg par exemple. Et je pense qu’avec les tailles des disques actuels, inutile de fragmenter son projet sur plusieurs disques ou lecteurs réseau (j’ose imaginer la gestion avec git…).

Et si vraiment le problème est que le « projet » ne tient pas sur un unique disque, des liens symboliques feront le job. Ainsi, je ne vois pas quelle est la spécificité des projets VC6 qui pose problème à Make, QMake ou CMake.

Si c’est le mode release ou debug :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
qmake project.pro "CONFIG+=debug"
make

[VBurel]

Sous Linux, les produits sont sous formes d’une arborescence avec un fichier Makefile maître qui fait tout...

Donc, je vous montre dans l'image ci-dessous, ce qu'est un projet dans un IDE:

On a donc un workspace, dans lequel on 1 ou plusieurs projects, avec une arborescence projet (indépendente de celle de vos disk) dans laquelle on peut monter des fichiers sources.

[floyer]

Je n'ai peut-être pas bien compris la notion de workspace, mais QtCreator permet de charger plusieurs projets en même temps.

Quant-à monter des fichiers dans un projet issu d'un arborescence tierce, j'ose espérer que ce n'est pas la fonction qui empêche les développeurs de développer sur Linux. Si un projet aussi complexe que LibreOffice ou Gimp a pu être compilé sur Linux, je suppose que beaucoup d'applications peuvent l'être aussi.

Ma conception d'un projet est qu'il s'agit d'un ensemble de fichiers en arborescence qui forme un tout cohérent. "monter" des fichiers d'ailleurs ne peut que complexifier l'intégration de tous les morceaux. (Accessoirement, il est possible de créer un Makefile qui récupère des fichiers de n'importe où, mais je doute que ce soit une bonne idée... par fois, il vaut mieux faire simple... La fonction "ajouter des fichiers existants" existe d'ailleurs sur QtCreator et permet de référencer des fichiers quel qu'en soit l'origine... Je saisi mal l'exclusivité de VC6 sur le sujet).

Et le montage de fichier externe depuis un IDE me semble vraiment anecdotique comparé à la sécurité que peut procurer un langage de type Rust... (A l'initiative de Mozilla - derrière une application multiplateforme complexe - dont les développeurs sentait plus un manque côté langage que côté IDE).

[VBurel]

Quant-à monter des fichiers dans un projets issus d'un arborescence tierce, j'ose espérer que ce n'est pas la fonction qui empêche les développeurs de développer sur Linux.

J'ai peur que si. c'est le concept même de projet de compilation. Aucun développeur d'applications ne veux s'emmerder avec du makefile.
Et si je parle de VC6 (qui à presque 30 ans) c'est parce que Eclipse n'est même pas un équivalent.

[floyer]

The proof is in the eating...

On a sur Linux des applications complexes et portables : LibreOffice, Firefox, Gimp... et il se trouve que les développeurs de Firefox étaient plus gênés par le langage C et sa sécurité que par les IDE à disposition au point de créer de toute pièce un nouveau langage moderne avec un compilateur performant. Je pense que si les IDE avaient été le point bloquant, ils auraient préféré s'atteler et aurait eu l'énergie et l'expertise pour perfectionner ce qui existe (que ce soit Eclipse, Netbeans, VS Code ou autre).

Peut-être que le problème est que sur Linux, c'est trop simple...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

apt source firefox-esr

Suffit pour récupérer les sources d'un logiciel même complexe sur Internet et le décompresser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

apt build-dep firefox-esr

Suffit pour récupérer depuis Internet les dépendances de ces sources et les installer.

Ensuite, dans le répertoire décompresseé << ./debian/rules build >> suffit à tout compiler. Inutile de "monter" à la main des fichiers selon l'emplacement exact, etc.

C'est assez facile de recompiler un projet même très complexe sous Linux Debian (dommage que la procédure change selon les distributions. C'est le vrai problème et des alternatives plus universelles se montent comme Snap)... Sous Windows, il faudrait récupérer sur Internet les bibliothèques une à une, installer chacune. Et s'il faut en plus les référencer avec un montage... Franchement, je préfère l'approche Linux Debian.

A titre d'exemple, j'ai voulu utiliser la bibliothèque Gtk sous Windows... et y ai perdu beaucoup d'énergie.


NB: QtCreator permet d'éviter de mettre les mains dans des Makefile

[VBurel]

On a sur Linux des applications complexes et portables : LibreOffice, Firefox, Gimp...

Oui, il y’a toujours de grosses équipes ou des expérimentés du makefile qui vont faire des trucs, mais avoir des outils de développement évolués comme un simple VC6, c’était s’assurer d’avoir une dynamique de développement d’une autre ampleur, notamment sur les nouveaux arrivants, qui ont besoin d’outils standard, ou qui sont habitué à des usages et des fonctionnalités qu’ils considèrent comme évidentes, universelles (comme un undo d’un logiciel d’édition).

[Uther]

Une condition qui ferait venir des développeurs (comme moi ou d’autre) c’est d’avoir une gestion de projets aboutie, ou l'on peut monter des fichiers sources (généralement sur disque réseau local) et définir des options de compilation pérennes.

C'est la base de ce que permet un IDE non ? J'ai pas utilisé énormément d'IDE pour C, mais il me semble bien que Qt Creator ou Code::Block proposent ça. Même VS Code avec juste quelque plugins peut faire ça.

Le but étant d’avoir une espace de travail ou l’ont construit des projets dans la durée, qu’on peut faire évoluer dans un univers cross-plateforme, comme on peut le faire avec XCODE et VisualStudio par exemple.

Pour le coup Visual Studio et XCode, c'est plutôt l'inverse de la portabilité vu qu'au contraire ils sont taillés respectivement pour Windows et Mac.

Après si tu veux que ça soit l'IDE qui gère le build et pas les Makefile via les différents outils pour les générer (autotools, CMake, ...), en effet il va y avoir un soucis, car c'est revoir tout le modèle de développement de Linux.
Si as peur des impacts potentiels de Rust dans le noyau, je pense que tu n'es pas prêt au bordel que ça serait pour les mainteneurs actuels de changer le mode de build de milliers de projets.

Pour moi c’est le prérequis pour faire venir des légions de développeurs sur linux, et le fait que ce ne soit pas déjà fait, comme une priorité première, est un très mauvais signal. Ca veut dire qu’il n’y a personne qui comprend les besoin des développeurs d’applications…

Bah pour le coup Rust est donc un très bon moyen de faire venir des développeurs sur Linux vu qu'il propose un écosystème cohérent, un système de build standard, une arborescence claire et efficace, un analyseur qui peut être facilement branché sur un IDE pour qu'il gère le langage.

Dans ce contexte, les débats sur la sécurisation de la mémoire ou l’implémentation d’autre langage que le C ou le C++ paraissent totalement hors sujet.

Tu mélanges encore le noyau et un OS en général. Une distribution Linux c'est des milliers de projets qui sont très décorrélés au niveau de la gestion de l'effort, le noyau n'étant que l'un d'entre eux. Déshabiller un projet ne permettra pas d'améliorer l'autre.
D'ailleurs la très très très très grande majorité du travail actuel rien que sur le noyau ne concerne pas l'introduction de Rust. Ne parlons même pas d'une distribution dans son ensemble.

La portabilité n'est pas une question. Je parle de la capacité de gérer des projets avec des sources éparpillés sur des disques locaux ou réseaux (possiblement utilisé dans d'autres projets sur d'autre plateforme) et avoir un projet de compilation comme on a sur tout IDE Visual ou XCode, et ca a commencé avec Borland C++ et Visual en 1995 ou par là.

Je sais pas si tu te rends compte que tu ériges un besoin très spécifique qui ne doit vraiment pas concerner grand monde comme la condition de succès absolue d'un écosystème. Pas grand monde ne travaille avec le source sur des lecteurs réseau de nos jours, on utilise des dépots de git, svn ou autre.
D'ailleurs un lecteur réseau étant montable comme n'importe quel répertoire, je vois pas pourquoi, n'importe quel IDE ne pourrait pas faire ça.

[VBurel]

Je sais pas si tu te rends compte que tu ériges un besoin très spécifique qui ne doit vraiment pas concerner grand monde comme la condition de succès absolue d'un écosystème.

Si cela ne concerne pas grand monde pourquoi la gestion de projet est le premier worflow des Visual, Xcode et autres dans le monde Windows/MAC ?

Le succès absolue, peut être pas, mais le manque de dynamisme de développement d'applicatifs, c'est certain.

[Uther]

Je parlais des lecteurs réseau. Pour les projets, j'avoue que j'ai du mal a comprendre où est le problème. Tous les IDE que je connais peuvent tout à fait gérer un workspace avec différents sous projets dans des répertoires séparés. Je travailles actuellement sur un projet comme cela avec QtCreator.

[smarties]

J'ai peur que si. c'est le concept même de projet de compilation. Aucun développeur d'applications ne veux s'emmerder avec du makefile.

C'est pour ça que beaucoup de langages ont un gestionnaire de paquets (pip/uv pour Python, cargo pour Rust, npm pour JS, ...)

[floyer]

Et vcpkg ou conan pour C/C++…

Ceci dit, c’est complémentaire… il peut y avoir un outil pour compiler et installer une bibliothèque, et un autre outil pour la récupération depuis internet, la gestion des dépendances (à un niveau macroéconomique), et l’appel du premier outil pour la compilation même.

Par exemple, avec Ada, le gestionnaire de package est Alire, et le l’outil de gestion de compilation est gnatmake ou gprbuild.

Avec OCaml, on va trouver respectivement Opam et Dune.

Comme Rust est arrivé après, ils ont évité de faire deux outils, ainsi on a Cargo.

Et oui, faire un Makefile portable peut être délicat, ainsi, on a des générateur de Makefile ou des remplaçant (qmake, cmake, xmkmf, autoconf…).

[VBurel]

Oui, mais toute cela ne remplace pas un gestionnaire de projet.

Finalement l'explication la plus simple qui explique pourquoi Linux reste dans sa niche, c'est qu'il n y' a jamais eu les outils pour faire venir les développeurs d'applications en fait.

Pourtant la barre n'était pas très haute, suffisait de faire l'équivalant d'un Borland C++ de 1996 ou un VC6 de 1998

[floyer]

Je ne saisi toujours pas ce que tu entends par gestionnaire de projet et que ne ferait pas QtCreator par exemple. Tu peux lui demander de référencer tous les fichiers que tu veux (même ceux qui sont sur un lecteur réseau). Mais honnêtement je doute que travailler avec des lecteurs réseaux soit la killer application d’un IDE moderne. Les lecteurs réseaux c’est quand ton disque est trop petit, ou que tu souhaite faire du collaboratif à l’ancienne sur un LAN (bon courage).

Pour moi, un IDE moderne intègre Git, génère des fichiers type Makefile qui donnent la liste des fichiers et les modalités de compilation (mais .dsp ou .pro qu’importe), facilite la compilation

Et pas mal de développeurs développent pour Linux. Mais peu de développeur desktop commerciaux car le ROI est moins important compte tenu de la base installée, de la culture open source qui privilégiera les alternatives libres, et la fragmentation des distributions (Debian, Ubuntu, RHEL, Suse…)

[VBurel]

Je ne saisi toujours pas ce que tu entends par gestionnaire de projet

CQFD

[Paul_Le_Heros]

Je ne suis pas aussi compétent que la plupart des intervenants ici, mais voici ce qu'il me vient à esprit quand je vous lis :

Le code "sure" ne dépend pas du langage, il dépend du développeur et des outils dont il se dotent pour maitriser, vérifier et valider l'exécution du code.

C'est ce que j'ai pensé depuis le début de ce sujet. C est donc un langage d'abord (?). D'ailleurs, les posts suivant montrent que des utilisateurs ont réglé les problèmes à leur manière, ces problèmes semblent correspondre à ceux que règle RUST) . C'eut été coté compilateurs et librairies associées au code produit qu'il aurait fallu régler les problèmes. Nous sommes "naturellement" si réfractaires aux changements ([TROLL] La persistance de WindOverDose en est probablement une des conséquences[/TROLL], sans parler des tonnes de fichiers sources à réécrire.

Par contre, côté serveur, Linux a fait sa place…

On oublie toujours Android, et avec lui, Linux a gagné en nombre !

Un noyau sans application ? Lequel ?

Hurd ? Mais il y a bien longtemps que j'ai lu quelque chose sur lui…

[floyer]

Lorsque je répondais «*un noyau sans application ? Lequel ?*», c’était en réponse à une insinuation que Linux n’avait pas d’application… et manifestement sur serveur il s’est imposé.

Et oui, il existe plusieurs OS qui occupent des niches trop étroites pour être considéré par les développeurs commerciaux. Hurd par exemple…

Ceci-dit, si je devais faire une application Firewall, Hurd (ou mieux, SeL4) aurait une faveur car pour la sécurité, un micro noyau semble réduire la criticité des CVE.

[Uther]

CQFD

Je suis pas sur de comprendre, sauf s'il fallait démonter que tu n'arrives pas à nous expliquer clairement ce qui manque selon toi aux IDE sous Linux ?

D'ailleurs, les posts suivant montrent que des utilisateurs ont réglé les problèmes à leur manière, ces problèmes semblent correspondre à ceux que règle RUST) .

Les techniques pour améliorer la fiabilité du C ne répondent que partiellement aux problèmes que traite Rust. Si ces techniques suffisaient on aurait plus de problèmes de corruption mémoire dans les navigateurs, OS, ... Or c'est toujours de loin la principale source de vulnérabilités critiques.

[floyer]

D’ailleurs en parlant d’éditeurs de logiciels qui ont des produits sous Linux, on peut citer JetBrains. JetBrains est une référence en matière d’IDE dans une multitude de langages. Difficile de considérer qu’il n’existe pas d’IDE valables sous Linux.

[VBurel]

D’ailleurs en parlant d’éditeurs de logiciels qui ont des produits sous Linux, on peut citer JetBrains.

ok, je vais essayer JetBrains / ( CLion a l'air très récent)...