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)...