Bonjour !
N'y aurait-il pas un moyen d'automatiser la reconstruction de l'EDI en fonction d'une liste de composants donnée ? Ou, à défaut, y a-t-il un moyen d'installer plusieurs composants à la fois et de reconstruire une seule fois ?
Bonjour !
N'y aurait-il pas un moyen d'automatiser la reconstruction de l'EDI en fonction d'une liste de composants donnée ? Ou, à défaut, y a-t-il un moyen d'installer plusieurs composants à la fois et de reconstruire une seule fois ?
- "L'Homme devrait mettre autant d'ardeur à simplifier sa vie qu'il met à la compliquer" - Henri Bergson
- "Bien des livres auraient été plus clairs s'ils n'avaient pas voulu être si clairs" - Emmanuel Kant
- "La simplicité est la sophistication suprême" - Léonard De Vinci
- "Ce qui est facile à comprendre ou à faire pour toi, ne l'est pas forcément pour l'autre." - Mon pèrei
Mes projets sur Github - Blog - Site DVP
Bonjour,
Suite aux récentes sorties de FPC 3.0 et Lazarus 1.6 rc1, je me suis dit que j'allais tester l'outil présenté dans cette discussion et qui ne nécessite normalement qu'un petit paramétrage de rien du tout, juste lui dire quoi télécharger.
La première partie s'est bien déroulée : téléchargement de FPC 3.0 et lancement de sa compilation mais là, patatras :Je compare le fichier concerné avec un autre (j'ai une vieille version sur une autre machine), ce sont exactement les mêmes entre la 2.6.x (qui compilait parfaitement bien il y a un mois) et la 3.0, j'en conclus que le mode de compilation (ou un chemin) a dû changer, je farfouille un peu sur le web et découvre qu'une nouvelle version de l'outil a été mise en ligne, peu après la sortie de la 3.0.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 /opt/devel/pascal/fpc/compiler/ppc1 -Ur -Xs -O2 -n -Fui386 -Fusystems -Fu/opt/devel/pascal/fpc/rtl/units/i386-linux -Fii386 -FE. -FUi386/units/i386-linux -dRELEASE -g -gl -O2 -Xs -CX -XX -di386 -dGDB -dBROWSERLOG -Fux86 -Sew pp.pas cp1251.pas(273,14) Error: Some fields coming before "map" were not initialized cp1251.pas(273,18) Fatal: Syntax error, "identifier" expected but ";" found Fatal: Compilation aborted
D'ici à ce que ça soit lié, il n'y a pas loin...
Bref, je télécharge cette nouvelle version et là, plus rien ne fonctionne : tous les paramètres longuement étudiés et mis dans le fichier ini de la première version ne sont plus pris en compte...
Pour faire simple, c'est une grosse régression et il va me falloir tout réétudier.
Et pendant ce temps, le bug dans la ListView n'avance pas, et tout ce qui s'appuie ensuite dessus non plus.
Que du bonheur...![]()
Salut,
C'est à moi que tu poses ces questions ? Alors la réponse est : je n'en sais absolument rien !
Ceci étant dit, automatiser la reconstruction de l'EDI en fonction d'une liste me semble bizarre, tout comme installer plusieurs composants à la fois, qui ne ressemble pas à la vraie vie.
Dans la vraie vie, on installe un composant par ci par là de temps en temps, et vient le moment où il faut faire la mise à jour de l'environnement de dev, qui consiste, la plupart du temps, en une tripotée de fichiers plus ou moins modifiés, et qui nous oblige à tout supprimer pour tout réinstaller : complètement stupide !
Je reste persuadé, sans aller jusqu'aux procédures de patch des fichiers eux-mêmes (quoique... Linux sait le faire pour par exemple les fichiers source du noyau [et Dieu sait qu'il y en a !]), qu'il suffirait de juste remplacer les fichiers version n par les fichiers version n+1 puis de recompiler pour avoir un environnement à jour.
Ok, cette procédure ne mettrait pas à jour les composants rajoutés par l'utilisateur, dans le cas où une màj serait dispo pour eux, mais c'est un autre problème (qui pourrait se résoudre de la même manière, d'ailleurs).
Bonjour,
Les erreurs citées dans mon précédent post étaient probablement dues à des changements dans les chemins et/ou les options de compilation de fpc 3.0.
Car j'ai fini par m'en sortir, en prenant le taureau par les cornes : au lieu d'utiliser l'outil de mise à jour pour faire une mise à jour 2.6.4 -> 3.0.0, j'ai carrément supprimé tout le dossier 2.6.4 et ai utilisé l'outil pour lui faire installer une 3.0.0 comme si la machine était vierge, et là ça fonctionne...
Dans la foulée j'ai ensuite lancé la migration de lazarus 1.4.4 -> 1.6rc1 et ça l'a fait en moins de temps qu'il n'en faut pour l'écrire.
Me reste à réinstaller les composants, et ça c'est nul de chez nul, heureusement que l'outil est capable de le faire.
Imaginez que vous alliez chez le garagiste pour changer le moteur de la voiture et qu'en sortant vous avez perdu la galerie sur le toit et l'attache-remorque à l'arrière, je trouve ça complètement dingue.![]()
Bonsoir,
C'est bien comme çà se passe si vous faites la mise à jour des sources par SVN au lieu de réinstaller Lazarus.
Je le fais avec la version en développement (trunk) mais comme vous êtes très prudentje pense que vous pourriez le faire avec la version en cours. Il faut sans doute choisir la bonne branche sur le dépôt SVN.
Tortoise SVN met à jour les sources. Il n'y a plus ensuite qu'à "Créer Lazarus avec le profil Clean up + Build all"
Tous les composants installés, même les vôtres sont alors recompilés.
Les quelques problèmes que j'ai pu rencontrer en faisant ainsi étaient dus à des composants à adapter aux évolutions ou à des composants que leur auteur présente comme "un atelier", bourrés de références circulaires, qui devaient être compilés plusieurs fois (composants que j'ai préféré supprimer tant ils étaient mal conçus).
André
Yop !
Ah ah ! Une piste intéressante !
Je mets ici un lien vers la doc officielle du truc, et en français s'il vous plait !
Mais il va y avoir beaucoup de lectures, je sens (par exemple le lien en français ci-dessus est moins complet que l'officiel, mais il a des scripts en plus...), et pas mal de questions, et d'essais...
Bon, je vais d'abord me créer une machine virtuelle dédiée à ça. À suivre...
Au départ j'ai installé sous Windows en suivant la méthode décrite aussi dans le wiki ici qui permet également la mise à jour de FPC. Les liens sont évidemment à adapter avec les versions actuelles.
Le téléchargement et la mise à jour des sources se fait avec TortoiseSVN. Après l'exécution d'un fichier .bat pour compiler FPC (c'est le plus long), il n'y a plus qu'à recompiler Lazarus depuis le menu Outils, sauf la toute première fois où il doit construit depuis un fichier .bat.
André
Bonjour,
avant d'aller plus loin, j'aimerais bien une (toute petite) explication à propos de tags, branches, trunk, etc.
Parce que je m'y perds...
Supposons que je veuille installer dans une machine vierge non pas la toute dernière version, mais une version un peu antérieure de fpc et de lazarus, pour ensuite tester les mises à jour. Comment dois-je m'y prendre ?
Merci pour le retour,
Bonjour,
Je ne sais si je peux vraiment t'aider car je n'utilise que la version sous Windows, et si j'ai bien compris tu travailles sous Linux.
Comme déjà dit j'utilise TortoiseSVN, interface graphique de SVN qui facilite bien les choses en s'intégrant dans l'explorateur. On peut trouver un mode d'emploi ici . On y trouve aussi des explications concernant SVN en mode console.
Une fois Tortoise ou un autre client SVN installé, il faut créer sur le PC le répertoire où tu veux installer les sources. A l'aide du client SVN il faut alors "extraire" les fichiers du dépôt SVN. Apparemment le dépôt des dernières sources officielles de Lazarus est à l'adresse http://svn.freepascal.org/svn/lazaru.../lazarus_1_4_4
Il est possible d'extraire les sources à la dernière révision (Head) ou à une précédente à définir.
Espérant que cela t'aidera...
André
Une autre vue pour montrer l'arborescence de mon installation de FPC/Lazarus.
Tout est dans le répertoire d:\freepascal.
N'utilisant que les sources issues du "trunk" ne pas tenir compte des répertoires binutils et fpc\2.6
Il est préférable de ne pas mélanger plusieurs "extractions de sources" dans le même répertoire. Je veux dire par là que le répertoire de FPC ne doit pas être un sous répertoire de Lazarus comme cela est fait dans l'installation standard.
Le dépôt de FPC est ici dans d:\freepascal\fpc\trunk et Lazarus dans d:\freepascal\laz.
Les composants personnels ou ajoutés depuis d'autres dépôts sont dans d:\freepascal\composants et non dans d:\freepascal\laz\components. Les compléments lazarus-ccr issus du dépôt https://svn.code.sf.net/p/lazarus-ccr/svn ont aussi droit à leur répertoire séparé.
André
Hello,
Ben c'est surtout que tu n'as pas répondu à la question toute simple qui me turlupine et que je repose :
Parce que sinon, Windows, Linux, pour moi c'est un peu pareil :-)Envoyé par Jipété
Mais je ne veux pas me mélanger les pinceaux avec ces tags, branches, et autres trunks : je ne sais pas quelle option choisir...
Complètement séparés sous Linux, donc pas de souci de ce côté-là.
Je prends bonne note, cependant, de ce réglage que je trouve sympathique :
Je l'adopterai certainement si je vois le bout du tunnel du merdier dans lequel je suis tombé en fin de création de Lazarus...
J'ai découvert un outil qui a l'air sympathique, fpcup, pour gérer le client subversion et lancer téléchargements, compilations, installations, etc., à condition de bien capter les réglages des fichiers ini (oui, il y en a 2 !), et j'ai passé la journée dessus, avec un gros sentiment de désespoir et de temps perdu parce que si tout s'est à peu près bien passé, la compilation et l'édition des liens du binaire Lazarus se solde par un échec cuisant avec un message plus que sibyllin : Can't call the linker, switching to external linking
Alors bien sûr j'ai farfouillé partout dans la machine (virtuelle, je vous rassure), j'ai même trouvé des vieux fichiers de config (alors que ce matin j'avais proprement désinstallé fpc, fpcsrc et lazarus, à croire que Linux c'est aussi merdique que Windows), mais rien qui me dise qu'est ce que c'est que ce linker, comment s'appelle-t-il, où faut-il le chercher...
La seule piste que j'ai c'est que l'erreur est remontée comme étant située dans le fichier install_laz/ide/lazbuild.lpr, à la ligne 1672 : j'y fonce et qu'est-ce que j'y trouve ? end., c'est la dernière ligne du fichier.
C'est donc très simple : si je ne passe pas ce mur, le bazar SVN pour moi c'est mort.
Allez, j'y retourne...
Difficile de te répondre avec précision, parce que les développeurs ont une assez grande liberté pour organiser leur dépôt. Il y a surtout des "traditions"...
En général dans trunk on trouve les dernières évolutions d'un projet. Dans branches et tags, les développeurs peuvent copier trunk ou une autre branche à une certaine révision pour y faire des essais ou pour figer dans un état déterminé. Il y a même des dépôts où on peut trouver des projets différents dans les branches. Il faudrait demander ou chercher sur le forum de Lazarus les règles que ce sont imposées les développeurs. Tu peux aussi explorer le dépôt avec le navigateur et consulter le journal des évolutions (à condition que les développeurs n'y soient pas trop succincts) pour savoir à quel stade est une branche.
Comme dit précédemment, il me semble que c'est la branche lazarus_1_4_4 qui devrait t'intéresser.
André
Merci pour les précisions, je vais aller fouiller...
Ben non, ce qui m'intéresse c'est d'installer plutôt la 1.4.0 et vérifier qu'elle s'installe et que ça fonctionne (ce qui n'est pas le cas à l'heure actuelle), et ensuite tester une migration 1.4.0 --> 1.4.2 et vérifier que les composants que j'aurais installés dans la 1.4.0 seront toujours présents, puis faire d'autres bidouilles et enfin upgrader en 1.4.4.
Et si là ça fonctionne encore, alors je pourrai dire que ce système est envisageable.
Mais pour le moment j'en suis loin car, si j'ai réussi à installer un mini IDE en suivant les instructions trouvées dans le README à la racine du dossier Lazarus puis ensuite le big IDE (mais dans les deux cas j'ai des problèmes de chemins qui font que ces 2 IDE's ne sont pas opérationnels), en tout état de cause, malgré des heures et des heures sur le web, ça ne fonctionne pas avec l'outil fpcup, prévu pour ça.
J'ai du pain sur la planche de ce côté-là...
Bonjour,
Je n'ai pas essayé avec d'autres méthodes que celle dont j'ai donné le lien (mot "ici" dans mon message d'hier à 00h05). Mais je peux te dire qu'avec celle-là ça marche puisque je mets mon installation régulièrement à jour. Le seul problème récurent c'est lors de la compilation de FPC; la compilation s'arrête parce que le répertoire units n'est pas correctement nettoyé. Il suffit de le supprimer manuellement ou d'inclure ce nettoyage dans le .bat.
Une différence cependant avec ce que semble-t-il tu es en train de faire. Je fais les mises à jour depuis toujours le même dépôt "trunk". Si j'ai bien compris, tu veux d'abord télécharger depuis un dépôt 1.4.0 puis ensuite mettre à jour avec un autre dépôt 1.4.2. etc...
Je doute que cela fonctionne, du moins pas aussi simplement qu'avec les commandes "SVN mettre à jour" ou "Mettre à jour à la révision..." depuis toujours le même dépôt. Mais je ne connais pas suffisamment SVN pour te dire si une commande le permet.
A ta place (mais je ne le suis pas) et si ton but est de tester l'évolution d'une version à une autre, avec le navigateur de dépôt je commencerai par identifier à quelles révisions correspondent chacune des versions que tu veux tester.
V1.4 -->R48774
V1.4.2 -->R49524
V1.4.4 -->R49931
tirées de la liste figurant dans le répertoire tags en supposant que dans ce répertoire figurent bien des versions figées et non des branches de tests.
Puis je ferai la première extraction depuis trunk à la révision 48774. Lors des mises à jour suivantes je préciserai la version voulue supérieure etc... sans changer de dépôt.
André
Yop !
"trunk", d'après ce que j'en lis là, vaudrait mieux pas y toucher. Après, chacun fait comme il le sent, heinIf the current trunk version is in a state of rapid change and unsuitable for much use unless you want to work on the compiler itself, you can stay on a version that is updated with fixes. To do this, you have to find out a stable branch that you want to track instead of the default trunk development version.
Bon, j'ai une piste, mais j'ai encore pas mal de boulot, je vous tiens au courant...
Ma piste était bonne, après de nombreux et laborieux essais (et à chaque fois c'est 15 à 20 minutes d'attente, entre le téléchargement et les compilations),plus des blagues de l'interface GUI (à ne surtout pas utiliser ! C'est une catastrophe...) : j'ai d'abord fait installer et compiler un fpc 2.6.0, que j'ai pu upgrader en 2.6.2 puis 2.6.4 tip-top, le seul souci mais il est de taille c'est que contrairement à l'option dont le nom et le commentaire avaient l'air sympathique :
je me suis amusé à changer un fichier sur lequel on avait travaillé il y aura bientôt deux ans, et les modifications sont perdues à chaque changement de version.
Code ini : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 ; In case you want to submit patches, it's nice to be able to update ; without overwriting your fixes: keeplocalchanges=true
C'est très nul, ça, je trouve.
Alors c'est peut-être moi qui utilise mal l'outil, mais je n'ai pas trouvé d'autre option...
Ça, c'était pour fpc.
Pour Lazarus, c'est la même catastrophe qu'hier : tout se passe bien pendant 10 minutes puis, lors de la compilation de Lazbuild, paf !, rateau.
Avec le même message d'erreur qu'hier, tellement nul que je ne sais absolument pas où chercher :
Code text : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 ... (9022) Compiling resource ../units/i386-linux/nogui/lazbuild.or [2015-10-26 18:34:04.367 Info] (9015) Linking ../lazbuild /usr/bin/ld: warning: ../link.res contains output sections; did you forget -T? [2015-10-26 18:36:23.495 Info] /opt/devel/pascal/laz/ide/lazbuild.lpr(1672,1) Error: (9014) Can't call the linker, switching to external linking /opt/devel/pascal/laz/ide/lazbuild.lpr(1672,1) Fatal: (10026) There were 1 errors compiling module, stopping Fatal: (1018) Compilation aborted
Ça doit être un problème de chemin, ou de raccourci, ou qqchse de ce style-là, parce qu'il suffit d'aller dans le dossier laz avec une console et de taper make et quelques minutes après on a un Lazarus parfaitement fonctionnel, la preuve :
Si mon client svn ne fait pas correctement son boulot, c'est la cata...
Un peu dégoûté, ce soir, après deux jours pleins là-dessus et pas de direction pour chercher une bonne idée...
Des nouvelles :
Ben non, c'était pas un problème de chemins : après avoir blindé le code de fpcup de writeln pour m'en dire plus et en avoir rajouté aussi dans le link.pas de fpc, j'ai pu avoir la satisfaction de constater que ce problème était lié à une absence de mémoire !
Vous parlez d'un message d'erreur pas explicite du tout
'fin bon, j'ai déclaré 2 Go à la machine virtuelle (au lieu de 1) et tout va bien maintenant de ce côté-là.
Du côté des patches, je considère que ce sont des choses à gérer à la main, trop dangereux d'automatiser ça, et pour les composants installés, il semblerait que l'outil fpcup soit capable de les gérer...
Plus d'infos quand ça sera testé.
Mais déjà, j'ai un meilleur moral qu'il y a 24 heures
Allez, j'y retourne, il y a encore plein de manips à faire avant de déclarer ça fonctionnel...
Yop !
De nouvelles nouvelles
Non, je ne suis pas tombé dans une faille spatio-temporelle, juste dans un truc tellement mal foutu que ça y ressemblait, et pendant un moment j'ai bien cru ne plus en sortir, mais la chance sourit aux audacieux, malgré des galères effroyables racontées dans le sous-forum voisin.
Bref, je crois que j'ai progressé dans la compréhension de ce machin qui gère les fichiers .ini d'une manière plus que farfelue : d'abord il y en a deux, en plus, selon la section qu'on appelle (oui, on n'a droit qu'à une seule section, truc de ouf' !) et ce qu'on veut faire (la misère a été l'installation des composants : deux jours dessus...) il y a besoin d'autres sections que le programme appelle mais il y a intérêt à utiliser les noms pré-définis codés en dur dans l'appli (nul !) parce que sinon ça fait très mal, heureusement que j'avais le code source (écrit en Lazarus) pour m'y retrouver.
Je vous passe les informations périmées dans les fichiers .ini ou dans les .pas (600 ko de lignes de code réparties dans 40 fichiers), ça aussi ça fait mal...
D'autres nouvelles demain, car là j'ai juste fait une simulation d'installation de deux composants, pour voir si je m'en sortais du flooding de la console par des messages d'erreur et, oui, ça y est.
Demain la vraie vie !
Alors dans la vraie vie, le nouvel outil (enfin, depuis quelques années maintenant) de gestion du système sous Linux, j'ai nommé la cochonnerie systemd m'aura fait perdre la moitié de la journée mais l'autre moitié aura été assez positive, on va dire.
Bien sûr il aura fallu créer avant la liste qui va bien dans un fichier ini, mettre tous les paquets dézippés dans un dossier "maître", se prendre pas mal la tête avec la structure de ce fichier ini mais à la fin, on gagne ça (8 composants à installer) en une seule commande (tout le monde aura reconnu le bout droit du bandeau supérieur de l'IDE) :
Je pense que ça sera très utile lors des prochaines mises à jour...
Partager