TIGCC: demandes de fonctionnalités (feature requests)... - Page 5

Cela dit, ce n'est effecitvement pas vital sur les plateformes utilisant une variante de l'ISO-8859-1 comme charset système.

C'est à dire, en base installée, une grande majorité.

* Les options du projet connaissent aussi les options de ld-tigcc.

Les options du linker font partie des options du projet.

* L'envoi aux calculatrices réelles (mais là encore l'EDI en Delphi est incomplet parce qu'il manque la gestion des câbles USB).

Il n'était en effet pas mentionné explicitement

* La compilation dans un dossier temporaire, ce qui permet: - de compiler un projet sans l'enregistrer et

Mouais. Je ne sais pas si ça doit être considéré comme une feature.

- d'utiliser les dossiers virtuels.

Pas tout le monde ne considère ça comme une feature dans 100% des use cases

Ce n'est pas aussi simple que ça, parce que ces fonctionnalités ont tous une partie graphique (progress bar etc.).

Je ne dis pas que c'est absolument trivial à réaliser, mais il existe, sur tous les OS, au moins un moyen de faire de l'IPC.

Et l'EDI ne peut pas compiler avec tprbuilder parce que c'est l'EDI qui doit enregistrer les fichiers dans le dossier temporaire parce que seul l'EDI connaît la version actuelle, qui n'est pas forcément enregistrée.

La plupart des IDE enregistrent les fichiers avant de compiler, puisque c'est nécessaire pour tous les vrais systèmes de build. Les IDE demandent éventuellement à l'utilisateur, si au moins un fichier a été modifié, s'il veut enregistrer avant de lancer le build.
L'absence de ce comportement de l'IDE Delphi / KTIGCC ne priverait pas grand monde, je pense.

Je me dis que ça pourrait aussi valoir pour Project -> Options...

C'est une fonctionnalité purement graphique, il n'y a rien à déplacer en ligne de commande là.

La deuxième partie de mon message se voulait plus générale que les outils en ligne de commande ("hors de l'IDE lui-même").
Qu'est-ce qui empêcherait de pousser Project -> Options hors de l'IDE ?
(Evidemment, il faudrait refactorer le code pour permettre à certains morceaux fonctionnellement communs à plusieurs exécutables d'être écrits une seule fois.)

Lionel Debroux (./121) :

Cela dit, ce n'est effecitvement pas vital sur les plateformes utilisant une variante de l'ISO-8859-1 comme charset système.

C'est à dire, en base installée, une grande majorité.

Je ne suis pas sûr que tes pourcentages soient valables pour TIGCC, le public visé étant un public de développeurs, donc les statistiques prises sur des échantillons d'utilisateurs moyens n'étant pas forcément valables. Pas mal des utilisateurs de TIGCC utilisent GNU/Linux, mais je ne connais pas les pourcentages exacts.

* Les options du projet connaissent aussi les options de ld-tigcc.

Les options du linker font partie des options du projet.

Oui, mais dans mon post que tu as cité, je ne parlais que de TIGCCLIB, j'avais oublié ld-tigcc.

* La compilation dans un dossier temporaire, ce qui permet:- de compiler un projet sans l'enregistrer et

Mouais. Je ne sais pas si ça doit être considéré comme une feature.

C'est une option, même pas l'option par défaut, mais c'est le comportement traditionnel de TIGCC IDE et certains utilisateurs (dont moi!) apprécient cette fonctionnalité.

- d'utiliser les dossiers virtuels.

Pas tout le monde ne considère ça comme une feature dans 100% des use cases

Alors c'est que vous ne l'utilisez pas correctement.

Si vous n'aimez pas les dossiers virtuels, rien ne vous empêche de faire correspondre les dossiers virtuels aux répertoires physiques. (C'est d'ailleurs ce qui se passe par défaut si vous créez un nouveau fichier dans un dossier virtuel. Et si vous créez vos fichiers en dehors de l'EDI, c'est déjà là votre première erreur. )

Je ne dis pas que c'est absolument trivial à réaliser, mais il existe, sur tous les OS, au moins un moyen de faire de l'IPC.

Utilisation totalement inutile de l'IPC, ça n'apporte absolument rien de faire ça avec l'IPC, ces fonctionnalités ont leur place dans l'EDI. Pourquoi veux-tu nous faire ça en IPC?

La plupart des IDE enregistrent les fichiers avant de compiler, puisque c'est nécessaire pour tous les vrais systèmes de build.

Je n'apprécie pas le sous-entendu dans la dernière partie de ta phrase.

Les IDE demandent éventuellement à l'utilisateur, si au moins un fichier a été modifié, s'il veut enregistrer avant de lancer le build.

TIGCC IDE et KTIGCC peuvent enregistrer automatiquement le projet aussi (c'est même l'option par défaut). Ce n'est juste pas forcément ce qu'on veut.

L'absence de ce comportement de l'IDE Delphi / KTIGCC ne priverait pas grand monde, je pense.

Si, moi, et donc ça ne changera pas.

Quand je veux tester un truc que je ne veux pas forcément garder, souvent, je modifie, je compile, puis je ferme l'EDI sans enregistrer. (Ou alors si je décide de garder la modification, j'enregistre à ce moment, après avoir compilé avec succès.) Je trouve ça très pratique et je ne vais pas supprimer cette fonctionnalité seulement parce que monsieur Debroux veut changer la manière dont fonctionne la compilation dans l'EDI (changement qui ne servirait absolument à rien parce que le comportement actuel est déjà codé).

Ce qu'il faut retenir, c'est qu'il y a de bonnes raisons pour lesquelles l'architecture des EDIs est telle qu'elle l'est.

Je vais le dire en clair: il n'est pas prévu de modifier la manière dont fonctionne la compilation dans TIGCC IDE / KTIGCC, sauf pour les petites modifications déjà effectuées dans le CVS de TIGCC et de KTIGCC 2 (compression ExePack intégrée au linker). Le fonctionnement actuel marche très bien et il restera tel quel (dans TIGCC, je ne peux pas parler pour le projet totalement différent de Lionel). De même, le format TPR ne subira pas de changements majeurs. Le seul changement que je retiendrais utile (mais je ne peux pas encore promettre que ce sera réalisé, ce sera pour KTIGCC 3 au plus tôt), ça seraient les groupes de projets (à la Visual Studio), ça répondrait aux demandes de Folco (qui veut pouvoir ouvrir un programme et ses libs dynamiques kernel en même temps) et des personnes qui demandent des fonctionnalités style makefile. Mais ça n'impliquerait pas une modification du format TPR, juste l'ajout d'un nouveau format (TPG?) qui contiendrait une liste de TPRs et les dépendances entre les TPRs (l'ordre dans lequel compiler quand on compile le groupe entier, par exemple si on a des libs statiques dans le mix).

La deuxième partie de mon message se voulait plus générale que les outils en ligne de commande ("hors de l'IDE lui-même").Qu'est-ce qui empêcherait de pousser Project -> Options hors de l'IDE ?

Que c'est une partie intégrante de l'EDI, ces options sont enregistrées dans le fichier .tpr quand on enregistre le projet (et seulement à ce moment - une fois de plus, on peut compiler un projet non enregistré!) et utilisées au moment de la compilation (directement par l'EDI depuis les structures en mémoire, sans passer par des fichiers - une fois de plus, on peut compiler un projet non enregistré! bis), je ne vois pas ce que tu veux externaliser.

Et puis la question est surtout: qu'est-ce que ça apporterait?

(Evidemment, il faudrait refactorer le code pour permettre à certains morceaux fonctionnellement communs à plusieurs exécutables d'être écrits une seule fois.)

Quel intérêt?

Et puis quels plusieurs exécutables? Il n'y aura plus qu'un seul EDI TIGCC avec KTIGCC 3.

Quand on a utilisé n'importe quel EDI autre que TIGCC, le système des dossiers virtuels semble quand même vraiment merdique La seule raison pour laquelle je ne m'en suis pas rendu compte au début, c'est que je n'avais jamais utilisé un autre EDI avant TIGCC ^^

Mais ce serait assurément un gros plus de remplacer cette horreur par quelque chose de plus cohérent, qui s'approche du fonctionnement de *tous* les autres environnements.

Quand à l'argument "je veux pouvoir tester un truc sans l'enregistrer", tu peux tout aussi bien te créer un projet "test" une bonne fois pour toutes et l'ouvrir à chaque fois que tu veux tester un truc. C'est très rapide à faire, tu ne conserves que ton dernier test sur le disque dur, ça ne colle pas des fichiers temporaires on-ne-sait où, et au moins ça permet d'adopter un comportement logique au niveau de l'EDI

Pas mal des utilisateurs de TIGCC utilisent GNU/Linux, mais je ne connais pas les pourcentages exacts.

Et au moins deux utilisateurs bien connus de TIGCC sous GNU/Linux n'utilisent pas KTIGCC (ou l'utilisent de manière exceptionnelle, pour le test).
(Enfin, pour ma part, j'étais utilisateur de TIGCC.)

Et si vous créez vos fichiers en dehors de l'EDI, c'est déjà là votre première erreur.

La plupart des vrais IDEs ne sont pas dérangés par cela.

La plupart des IDE enregistrent les fichiers avant de compiler, puisque c'est nécessaire pour tous les vrais systèmes de build.

Je n'apprécie pas le sous-entendu dans la dernière partie de ta phrase.

Les TPR sont un système de build simpliste, qui est mal adapté à plusieurs use cases bien identifiés, que permettent l'utilisation de `tigcc`(soit en script, soit carrément en Makefile ou autre vrai système de build).

il n'est pas prévu
de modifier la manière dont fonctionne la compilation dans TIGCC IDE / KTIGCC

Ca, on savait, mais je voulais le voir écrit en clair.

La deuxième partie de mon message se voulait plus générale que les outils en ligne de commande ("hors de l'IDE lui-même"). Qu'est-ce qui empêcherait de pousser Project -> Options hors de l'IDE ?

Que c'est une partie intégrante de l'EDI, ces options sont enregistrées dans le fichier .tpr quand on enregistre le projet (et seulement à ce moment - une fois de plus, on peut compiler un projet non enregistré!) et utilisées au moment de la compilation (directement par l'EDI depuis les structures en mémoire, sans passer par des fichiers - une fois de plus, on peut compiler un projet non enregistré! bis), je ne vois pas ce que tu veux externaliser.
Et puis la question est surtout: qu'est-ce que ça apporterait?

Si on externalise
[ul][li]la communication avec les émulateurs et les calculettes réelles[/li]
[li]le code de build du système limité et spécifique à TIGCC que sont les TPR[/li]
[li]la modification des options globales (évidemment, puisque le TPR ne sait gérer que ça) du système spécifique à TIGCC que sont les TPR, pour la compatibilité antérieure[/li][/ul]
que reste-t-il comme features vraiment utiles (comme écrit plus haut, la conversion de charset n'en est pas une) spécifiques à TIGCC IDE / KTIGCC ?
Pour être plus clair: tu veux maintenir un couplage fort [TIGCC IDE - KTIGCC] / [système de build spécifique à TIGCC] / [rares capacités spécifiques à TIGCC IDE - KTIGCC]. On se demande comment baisser ce couplage pour faciliter l'utilisation d'IDEs plus puissants, avec des comportements moins bizarres, et de vrais systèmes de build.

La seule raison pour laquelle je ne m'en suis pas rendu compte au début, c'est que je n'avais jamais utilisé un autre EDI avant TIGCC ^^

Pareil pour moi.

Quand à l'argument "je veux pouvoir tester un truc sans l'enregistrer", tu peux tout aussi bien te créer un projet "test" une bonne fois pour toutes et l'ouvrir à chaque fois que tu veux tester un truc. C'est très rapide à faire, tu ne conserves que ton dernier test sur le disque dur, ça ne colle pas des fichiers temporaires on-ne-sait où, et au moins ça permet d'adopter un comportement logique au niveau de l'EDI

Tout à fait.
C'est comme ça que fonctionnent mon fichier des tests d'ExtGraph, que j'ai aussi parfois utilisé pour d'autres tests, qui fait environ 240 KB, et l'ancien fichier de tests, utilisé à l'époque du reverse-engineering d'AMS, qui est il me semble entre 100 et 200 KB, il me semble.
Le fait d'enregistrer le projet permet de garder une trace des tests qu'on a fait et de les rejouer plus tard (ça m'est arrivé !). Le rejeu pour vérification pouvant d'ailleurs être fait par une autre personne (c'est bien pour ça que je t'ai envoyé à une époque mon fichier contenant tests et notes sur le reverse-engineering d'AMS, Kevin: faciliter la vérification de mes contributions).

even if you can justify your recommendations, people can frequently equally justify their actions against your recommendations

Keep this in mind, Kevin...

Lionel Debroux (./124) :

Quand à l'argument "je veux pouvoir tester un truc sans l'enregistrer", tu peux tout aussi bien te créer un projet "test" une bonne fois pour toutes et l'ouvrir à chaque fois que tu veux tester un truc. C'est très rapide à faire, tu ne conserves que ton dernier test sur le disque dur, ça ne colle pas des fichiers temporaires on-ne-sait où, et au moins ça permet d'adopter un comportement logique au niveau de l'EDI

Tout à fait.
C'est comme ça que fonctionnent mon fichier des tests d'ExtGraph, que j'ai aussi parfois utilisé pour d'autres tests, qui fait environ 240 KB, et l'ancien fichier de tests, utilisé à l'époque du reverse-engineering d'AMS, qui est il me semble entre 100 et 200 KB, il me semble.
Le fait d'enregistrer le projet permet de garder une trace des tests qu'on a fait et de les rejouer plus tard (ça m'est arrivé !). Le rejeu pour vérification pouvant d'ailleurs être fait par une autre personne (c'est bien pour ça que je t'ai envoyé à une époque mon fichier contenant tests et notes sur le reverse-engineering d'AMS, Kevin: faciliter la vérification de mes contributions).

Je rajouterai que les IDE modernes possèdent un historique des enregistrements s'il y a besoin de revenir en arrière.

Lionel Debroux (./117) :
Une autre possible est, au contaire, de déplacer le maximum de choses hors de l'IDE lui-même, et faire de l'IDE un front-end pour les outils qui font le vrai travail. Ca vaut au moins pour:
pour la communication avec les émulateurs & calculettes réelles
pour la construction d'un projet (en ajoutant à tprbuilder un mode de compatibilité avec le comportement de IDE vis à vis des dossiers virtuels)

Cà me parait être une bonne solution et très proche de la philosophie UNIX: il n'y a qu'à regarder tous les softs de gravure ou de création de DVD. Ce sont tous des front-ends graphiques qui pilote dvdauthor ou les cdrtools.
Et puis çà te donne une certaine modularité.

C'est tout à fait ce que j'avais envie d'exprimer.
Tu le fais de façon plus courte et plus expressive que moi

Lionel Debroux (./124) :

Et si vous créez vos fichiers en dehors de l'EDI, c'est déjà là votre première erreur.

La plupart des vrais IDEs ne sont pas dérangés par cela.

TIGCC IDE / KTIGCC non plus. Mais c'est plus compliqué de faire des fichiers dans des sous-dossiers tout en faisant correspondre les dossiers virtuels aux dossiers physiques comme ça.

Et où est l'intérêt? (Une question que je me pose à chaque fois quand tu proposes des utilisations pas du tout prévues de l'EDI et à laquelle je ne trouve jamais de réponse dans tes posts...) L'intérêt d'un EDI est justement qu'on travaille entièrement à l'intérieur de cet EDI. Pourquoi te compliquer la vie en créant le fichier ailleurs?

Les TPR sont un système de build simpliste, qui est mal adapté à plusieurs use cases bien identifiés, que permettent l'utilisation de `tigcc`(soit en script, soit carrément en Makefile ou autre vrai système de build).

Lesquels?

Ceux qui ont déjà été cités:
* flags d'optimisation différents par fichiers - ce ne sera plus un problème avec GCC 4.4. (Avez-vous (Godzil et toi) déjà commencé à travailler sur un portage de GCC 4.3 ou 4.4? Ou comptez-vous parasiter mon travail pour les parties de TIGCC nécessitant le plus de travail? )
* groupes de projet. C'est une fonctionnalité à intégrer au système actuel (en permettant des groupes interdépendants de TPRs), non pas une raison de tout remplacer.

Pour être plus clair: tu veux maintenir un couplage fort [TIGCC IDE - KTIGCC] / [système de build spécifique à TIGCC] / [rares capacités spécifiques à TIGCC IDE - KTIGCC]. On se demande comment baisser ce couplage pour faciliter l'utilisation d'IDEs plus puissants, avec des comportements moins bizarres, et de vrais systèmes de build.

Effectivement, je veux proposer un environnement intégré, facile à utiliser et commun quelle que soit la plateforme sur laquelle on code (ce qui permet aussi de suivre les mêmes tutoriaux sans devoir s'adapter à des comportements différents des différents EDIs), pas des morceaux éparpillés mettant l'utilisateur devant un puzzle à résoudre. Je trouve que c'est cette intégration qui met TIGCC loin devant d'autres chaînes d'outils semblables (genre z88dk) et une raison importante de son succès.

Je pense que tu as perdu la signification de la lettre 'I' dans EDI.

Quand à l'argument "je veux pouvoir tester un truc sans l'enregistrer", tu peux tout aussi bien te créer un projet "test" une bonne fois pour toutes et l'ouvrir à chaque fois que tu veux tester un truc. C'est très rapide à faire, tu ne conserves que ton dernier test sur le disque dur, ça ne colle pas des fichiers temporaires on-ne-sait où, et au moins ça permet d'adopter un comportement logique au niveau de l'EDI

Tout à fait.

Marche pas si ce qu'on veut tester est une petite modification à un grand projet.

even if you can justify your recommendations, people can frequently equally justify their actions against your recommendations

Keep this in mind, Kevin...

Je ne suis pas d'accord avec cette phrase ni avec le fait qu'elle s'applique ici.

Uther (./125) :
Je rajouterai que les IDE modernes possèdent un historique des enregistrements s'il y a besoin de revenir en arrière.

Et j'enregistre les anciennes versions où?

Le système actuel est simple et donne des .tpr faciles à distribuer (à condition de ne pas utiliser des fichiers en dehors du répertoire du projet), si je me mets à sauvegarder d'anciennes versions, on va se retrouver avec des dossiers de projets de plusieurs MO et en gros ça réinvente les SCMs.

roms (./126) :
Cà me parait être une bonne solution et très proche de la philosophie UNIX: il n'y a qu'à regarder tous les softs de gravure ou de création de DVD. Ce sont tous des front-ends graphiques qui pilote dvdauthor ou les cdrtools.Et puis çà te donne une certaine modularité.

Cette manière de fonctionner a aussi des désavantages, c'est pour ça qu'il y a aussi une tendance de remplacer ces exécutables externes par des libs (par exemple libkdcraw utilise maintenant libraw plutôt qu'un exécutable dcraw externe, Ark utilise libarchive et libzip dans KDE 4 et il y a aussi une libburn en développement - il y a aussi la link.dll de TIGCC/W32, mais malheureusement l'interface n'est pas optimale, il n'y a pas de fonctionnalités de type reportage du progrès et il faut de toute façon appeler plusieurs exécutables en ligne de commande pour la compilation, donc j'ai préféré utiliser l'exécutable externe dans KTIGCC).

Et ce qui est en commun dans tous ces frontends, c'est que les dialogues d'options font partie du frontend, ils ne s'externalisent pas!

squalyl (./97) :
c'est faisable, c'est demandé par ton client. Ca devient la chose la plus importante à réaliser.

Non. S'il demande mais s'il paye pas pour, il l'a dans l'os. J'ai un budget à tenir moi et de la surproduction à créer

Et où est l'intérêt? (Une question que je me pose à chaque fois quand tu proposes des utilisations pas du tout prévues de l'EDI et à laquelle je ne trouve jamais de réponse dans tes posts...) L'intérêt d'un EDI est justement qu'on travaille entièrement à l'intérieur de cet EDI. Pourquoi te compliquer la vie en créant le fichier ailleurs?

Je ne vois pas trop de use case pour la création de fichiers hors de l'IDE. Tu es content ?

Les TPR sont un système de build simpliste, qui est mal adapté à plusieurs use cases bien identifiés, que permettent l'utilisation de `tigcc`(soit en script, soit carrément en Makefile ou autre vrai système de build).

Lesquels?

Si j'étais mesquin, je répondrais exactement ce que tu as répondu en ./115:

Non, je ne veux pas. Franchement, je l'ai répété au moins 100 fois et à chaque fois je dois me rappeler de tout et le retaper (je ne l'ai pas prêt pour le copier-coller), j'en ai marre, utilise le moteur de recherche...

Mais la réponse se trouve à un endroit où il n'y a pas besoin de la copier-coller: notre tracker de bugs et de feature requests (regroupés sous le vocable "tickets", dans Trac).

(Avez-vous (Godzil et toi) déjà commencé à travailler sur un portage de GCC 4.3 ou 4.4? Ou comptez-vous parasiter mon travail pour les parties de TIGCC nécessitant le plus de travail? )

Personne n'a indiqué travailler sur le portage du TIGCC patch vers un GCC plus récent.
Il y a bien d'autres éléments de la todo list pour nous tenir occupés, tu sais. Nous avons commencé à introduire un processus de qualité (bug + feature request + patch tracker, ML, un vrai SCM), il faut continuer (automatisation des builds, etc.). Et puis il y a bien sûr les feature requests fonctionnelles.

Je pense que tu as perdu la signification de la lettre 'I' dans EDI.

Le fait d'être "I" n'empêche pas d'être modulaire. Ce qu'à notre avis, TIGCC IDE et sa copie presque 1:1 KTIGCC ne sont pas assez.

Je rajouterai que les IDE modernes possèdent un historique des enregistrements s'il y a besoin de revenir en arrière.

Et j'enregistre les anciennes versions où?

En mémoire, sur le disque avec des diffs dans un sens ou dans l'autre, sur le disque avec une forme ou une autre de DB... ce ne sont pas les solutions techniques qui manquent.
L'historique des enregistrements a une granularité plus fine que les SCM, c'est peut-être plus un complément des SCM qu'une réinvention.

Cette manière de fonctionner a aussi des désavantages, c'est pour ça qu'il y a aussi une tendance de remplacer ces exécutables externes par des libs

Oui. Mais TIGCC & GCC4TI n'en sont toujours pas à ce stade-là, même si on est en train (notamment dans ce topic) de discuter de comment arriver à réduire la duplication de code. En vue de coopérer, bien sûr... si on arrive à se mettre d'accord.

Lionel Debroux (./130) :
Mais la réponse se trouve à un endroit où il n'y a pas besoin de la copier-coller: notre tracker de bugs et de feature requests (regroupés sous le vocable "tickets", dans Trac).

... auquel je n'ai en principe pas accès parce que vous firewallez mon IP.

Personne n'a indiqué travailler sur le portage du TIGCC patch vers un GCC plus récent.Il y a bien d'autres éléments de la todo list pour nous tenir occupés, tu sais. Nous avons commencé à introduire un processus de qualité (bug + feature request + patch tracker, ML, un vrai SCM), il faut continuer (automatisation des builds, etc.). Et puis il y a bien sûr les feature requests fonctionnelles.

Bref, vous vous limitez à bosser sur les petits détails faciles et vous comptez parasiter le projet TIGCC original pour tout ce qui est difficile. C'est sûr que c'est facile de "maintenir" un projet comme ça.

Le fait d'être "I" n'empêche pas d'être modulaire. Ce qu'à notre avis, TIGCC IDE et sa copie presque 1:1 KTIGCC ne sont pas assez.

À mon avis, ce n'est pas une histoire de modularité, mais bien d'intégration. Des petits "modules" éparpillés ne donneront jamais une intégration comparable à ce que TIGCC IDE et KTIGCC proposent.

En mémoire, sur le disque avec des diffs dans un sens ou dans l'autre, sur le disque avec une forme ou une autre de DB... ce ne sont pas les solutions techniques qui manquent.

Les solutions ne manquent pas, mais ils ont tous leurs désavantages et je ne suis pas convaincu que cette fonctionnalité soit nécessaire dans un EDI pour calculatrices.

... auquel je n'ai en principe pas accès parce que vous firewallez mon IP.

J'ai demandé à Godzil ce qui se passe.
Je sais que la machine est pourvue de mécanismes bannissant ceux qui essaient un peu trop lourdement de se connecter dessus...

Bref, vous vous limitez à bosser sur les petits détails faciles et vous comptez parasiter le projet TIGCC original pour tout ce qui est difficile.

C'est du moins l'interprétation que tu fais de ce que j'ai écrit... Ce que j'ai posté:
[ul][li]une indication du fait que ce n'est a priori pas en cours;[/li]
[li]une indication du fait qu'il y a bien autre chose à faire sur le projet;[/li][/ul]
ne dit absolument rien sur l'intention ou l'absence d'intention de s'occuper de GCC.

Pourquoi faire TIGCC open source si tu ne veux pas qu'on le modifie indépendamment de toi ? c'est vraiment un comportement de logiciel propriétaire !

Lionel Debroux (./130) :
Je ne vois pas trop de use case pour la création de fichiers hors de l'IDE. Tu es content ?

Créer des fichiers standardisés avec un script par exemple, on fait ça au boulot pour avoir directement la bonne mise en forme des différents entêtes de commentaires, avec l'auteur, la date de création, etc.
L'IDE que nous utilisons est intégralement scriptable et intègre une ligne de commande accessible en écriture, c'est drôlement pratique.

Ximoon (./134) :
et intègre une ligne de commande accessible en écriture, c'est drôlement pratique.

C'est un des supers avantages de Kate sur KTIGCC, et on s'en passe plus !

D'ailleurs, la compilation sort ses messages dans cette ligne de commande et c'est elle que l'IDE utilise pour retrouver la ligne des erreurs et tout. Le nombre d'avantages de ça est assez conséquent j'ai trouvé. (pour référence, c'est visual slick edit)

Bah, pour un projet TIGCC, il faut utiliser l'entête standardisé de TIGCC IDE / KTIGCC.

// C Source File
// Created 2009-01-05 00:36:53

Bon OK, c'est en général la première chose à passer sous la touche Suppr ici, mais la date de création est là.

mais le format de date n'est pas normalisé ISO 8601

Dans KTIGCC il l'est.

A quand une konsole dans KTIGCC ? Ca devrait être faisable avec les ressoruces de KDE

Mais ça ne sert à rien.

Sauf que si je veux autre chose que l'entête toute moche pondue par TIGCC, je fais quoi ? Je demande une nouvelle fonctionnalité ?

Ximoon (./136) :
(pour référence, c'est visual slick edit)

Génial en effet, mais cher

Kevin Kofler (./141) :
Mais ça ne sert à rien.

putain la réponse... t'étonnes pas que tout le monde laisse tomber ton soft obsolète alors...

Ximoon (./142) :
Sauf que si je veux autre chose que l'entête toute moche pondue par TIGCC, je fais quoi ? Je demande une nouvelle fonctionnalité ?

Oui. Ça pourrait aussi être intéressant pour mettre par exemple l'entête GPL sur tous les fichiers. (Ma méthode actuelle pour ce genre de trucs, c'est le copier-coller. )

Folco (./144) :

Kevin Kofler (./141) :
Mais ça ne sert à rien.

putain la réponse... t'étonnes pas que tout le monde laisse tomber ton soft obsolète alors...

Il n'est pas obsolète, c'est le travail avec une console qui l'est.

Franchement, ça ne rentre pas du tout dans les utilisations prévues de l'EDI, le but est de tout pouvoir faire dans l'EDI, si tu as besoin d'une console, tu as déjà fait quelque chose de mauvais quelque part.

J'utilise couramment la recherche de fichier ou grep, c'est bien commode. Je suis quasiment au niveau de la connaissance 0 du scripting sous *nix, mais ça me servirait sûrement aussi si je connaissais. Et ça me sert à compiler, ce que (K)TIGCC est infoutu de faire dans les cas qui m'intéressent.

(et je disais obsolète pour les vieux headers style cp/m doorsos qui trainent )

Folco (./146) :
J'utilise couramment la recherche de fichier ou grep, c'est bien commode. Je suis quasiment au niveau de la connaissance 0 du scripting sous *nix, mais ça me servirait sûrement aussi si je connaissais.

Je te signale que la recherche intégrée à KTIGCC gère les expressions régulières. (Un autre petit avantage de KTIGCC sur TIGCC IDE, et ça vient pratiquement tout seul grâce à KDE.)

Et ça me sert à compiler, ce que (K)TIGCC est infoutu de faire dans les cas qui m'intéressent.

C'est juste que tu ne l'utilises pas comme il faut (un projet par lib).

Oui, des groupes de projets seraient pratiques, mais on peut tout à fait faire sans sans contourner le système de compilation. Compiler dans une console n'est pas du tout un usage prévu de l'EDI.

Tu montres exactement ce que je veux dire: tu veux une console pour contourner ce que tu perçois comme des limitations de l'EDI, la bonne solution est de corriger ces limitations (là où elles existent vraiment), pas de rajouter une console. Oui, ça prend plus de temps, mais non, tu ne trouveras pas de solutions à court terme dans TIGCC. Dans GCC4TI peut-être, à eux de voir, mais moi je veux des solutions à long terme.

Et puis tu n'as qu'à coder des programmes en un morceau comme tout le monde plutôt que des overlays à la DOS ou CP/M.

Ta philosophie "c'est à l'utilisateur de s'adapter à l'outil", philosophie que tu appliques à TIGCC, n'est pas la vérité universelle absolue... Ne citons que SAP (fabricant de logiciel propriétaire vilain, on sait), qui fait des outils modulaires et assez facilement modelables, et travaille avec ses clients pour faire des outils qui collent au mieux aux besoins des clients.

Compiler dans une console n'est pas du tout un usage prévu de l'EDI.

Autrement dit, tprbuilder est un bug et pas une feature ?

[Dans ce qui suit, je m'essaie à la critique à la façon Kevin telle qu'on la ressent depuis des années: dénigrer les méthodes, les idées et le travail des autres. J'utilise certaines de ses expressions, marquées en italique.]


TIGCC IDE / KTIGCC ne sait pas faire les groupes de projets. Je nourris quelques craintes quant à leur implémentation, vu:
[ul][li]le temps que tu mets à merger des patches triviaux (dont l'existence même montre que contrairement à ce que tu écris, on a essayé et on essaie toujours de bosser avec toi)[/li]
[li]la pauvreté de tes méthodes de génie logiciel (SCM bien connu comme merdique et dépassé, pas d'infrastructure de build automatique, pas de moyen public et adapté de tracker les bugs, les feature requests, les patches, etc.). C'est pourtant bien connu qu'une parcimonie dans l'utilisation de méthodes de génie logiciel augmente les risques de faire des bêtises.[/li][/ul]
Par conséquent, l'usage prévu de l'EDI est donc de créer, maintenir et ouvrir un par un douze projets quand je veux compiler TICT-Explorer. C'est irrésistiblement user-friendly

Ah, c'est vrai, Thomas et par la suite moi n'avions qu'à faire un binaire unique qui non seulement fonctionne sur tous les modèles, mais qui de plus embarque les traductions complètes pour les six langues supportées. Ca, au moins, TIGCC IDE / KTIGCC saurait faire.
Et après, sous la contrainte de cette significative augmentation de taille, faire tout notre possible pour optimiser taille. Alors même que le mode compilation avec optimisations interprocédurales - déconseillé et non supporté par toi - est inaccessible avec l'IDE, il faut passer par un système de build plus flexible (en fait, appeler directement gcc, patcher et ld-tigcc, parce que tigcc et tprbuilder en sont aussi incapables que l'IDE) si on veut y avoir accès.

(D'ailleurs, rappelons que patcher est plutôt un hack, et de toute façon une solution de facilité pour implémenter dans les gcc / as de TIGCC des features absentes de gcc / as upstream. La bonne façon de faire, la solution à long terme, serait de modifier correctement gcc et as, même si c'est difficile, et pourquoi pas, de contribuer à upstream une partie de ces modifications-là - après tout, il n'y a probablement pas que sur cette architecture qu'on pourrait avoir envie d'utiliser du reg-relative.)

[fin du passage rédigé à la façon Kevin]

Et puis tu n'as qu'à coder des programmes en un morceau comme tout le monde plutôt que des overlays à la DOS ou CP/M.

Les overlays à la DOS ou CP/M (entre bien d'autres systèmes) étaient des moyens de s'adapter aux ressources limitées des machines sur lesquelles ces systèmes tournaient, et par là-même, permettre aux utilisateurs de se servir plus à fond du potentiel des machines. Enfin bon, ce que j'en dis...


[EDITs multiples]

Lionel Debroux (./130) :

Et où est l'intérêt? (Une question que je me pose à chaque fois quand tu proposes des utilisations pas du tout prévues de l'EDI et à laquelle je ne trouve jamais de réponse dans tes posts...) L'intérêt d'un EDI est justement qu'on travaille entièrement à l'intérieur de cet EDI. Pourquoi te compliquer la vie en créant le fichier ailleurs?

Je ne vois pas trop de use case pour la création de fichiers hors de l'IDE. Tu es content ?

Bon alors sur ce point je ne suis pas d'accord. C'est précisément pour cette raison que je n'utilise pas Eclipse pour le dév amateur par exemple, impossible de créer un projet dans un dossier qui a déjà des fichiers (p. ex. téléchargé sur le net ou fait avec un autre IDE). Il faut absolument qu'il y ait un répertoire parent, qu'il y foute son .metadata plein de petits fichiers pourris, que la synchro soit mauvaise si on fait quoi que ce soit en dehors de l'IDE, etc. pareil pour Code::Blocks et autres qui veulent absolument gérer leur projet eux-même: impossible de faire un projet simple qui utilise un .bat pour compiler par exemple.
Du coup j'utilise cet overkill de Visual Studio, tu peux créer tes fichiers depuis l'explorateur et les drag & drop au projet (ceux que tu souhaites inclure, pas toute l'arborescence bien sûr).

c'est faux, pour codeblocks tu peux faire un projet avec du code existant, tu peux même utiliser ton make file personnel si tu veux pas le système de build de c::b