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 ?
Version imprimable
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 ?
Peut être en passant pas un script BATCH comme l'installation de CodeTyphonCitation:
Envoyé par Roland Chastain
Salut,
C'est à moi que tu poses ces questions ? Alors la réponse est : je n'en sais absolument rien ! :mouarf:Citation:
Envoyé par Roland Chastain
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).
Bonsoir,
C'est bien comme çà se passe si vous faites la mise à jour des sources par SVN au lieu de réinstaller Lazarus.Citation:
Envoyé par Roland Chastain
Je le fais avec la version en développement (trunk) mais comme vous êtes très prudent;) je 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 !Citation:
Envoyé par alanglet
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 :Citation:
Envoyé par alanglet
Parce que sinon, Windows, Linux, pour moi c'est un peu pareil :-)Citation:
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à.Citation:
Envoyé par alanglet
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...Citation:
Envoyé par alanglet
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 :cry:
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"...Citation:
Envoyé par Jipété
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.Citation:
Envoyé par alanglet
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, hein ;)Citation:
If 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 :Citation:
Envoyé par Jipété
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:
2
3
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:
2
3
4
5
6
7
Ç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 :
Pièce jointe 191055
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 !Citation:
Envoyé par Jipété
Vous parlez d'un message d'erreur pas explicite du tout :roll:
'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 :ccool:
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 8-)) 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.Citation:
Envoyé par Jipété
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) :
Pièce jointe 191641
Je pense que ça sera très utile lors des prochaines mises à jour...
3 jours plus tard...
Pièce jointe 191873
Légende de l'image :
- en bleu les dossiers,
- en vert les fichiers exécutables (binaire, script)
- en blanc les fichiers texte.
J'ai donc créé dans /opt un dossier "devel" dans lequel j'ai créé un sous-dossier "pascal", dans lequel j'ai créé trois sous-dossiers : "composants", "fpcup", et "patches". Les autres seront créés automatiquement.
"composants" et "patches" comme les noms l'indiquent, ne nécessitent pas d'explications, sauf une, pour les patches, qu'il faut passer à la main : je préfère cette méthode qui permet de vérifier que le patch qu'on va appliquer correspond bien à un fichier qui en a besoin (des fois qu'il ait été mis à jour).
Pour l'heure ça ne concerne (pour moi) que fpreadtiff.pas dans fpc (dont on a parlé ici il y a un an ou deux), et easylazfreetype.pas pour laz, qui sera probablement mis à jour un jour, d'où le contrôle à la mano !
La grosse partie du boulot se trouve dans le dossier "fpcup" dans lequel on trouve :
- un binaire recompilé par mes soins suite à microscopiques modifications dans les sources, mais ça m'a bien aidé ;
- un fichier fpcup.ini n'est n'est pas celui d'origine (que vous sauvegarderez dans un coin, on ne sait jamais) et qui m'a fait souffrir le martyre parce que c'est très mal expliqué et même parfois carrément périmé...
- un autre fichier d'intialisation "settings.ini" que je n'ai pas eu le courage d'enlever (on ne sait jamais...) mais que je n'ai pas modifié ;
- et enfin le script "start_fpcup.sh" qui fait le boulot, créé par mes soins et commenté, parce que l'articulation de tout ça est un peu casse-gueule.
Mais ça m'aura quand même permis de, dans l'ordre :
- installer fpc 2.6.0 et laz 1.4.0
- upgrader fpc vers 2.6.2
- upgrader fpc vers 2.6.4
- installer les composants dans laz
- upgrader laz vers 1.4.2
- upgrader laz vers 1.4.4
et tout ça en ne faisant qu'une modif (ou deux) à la fois dans le .ini, et une ou même pas dans le script, en fonction de la cible.
Deux exemples pour illustrer l'idée : upgrader une version se définit dans l'ini, installer les composants de laz plutôt que l'ide se définit dans le script.
Le seul souci qui reste c'est cette perte du paramètre de langage dans l'IDE de laz après un upgrade... Je ne renonce pas à l'idée de rajouter une ligne ou deux dans le script pour remettre ça d'équerre :-)
La modif dans les sources de fpcup (c'est bien, c'est écrit en Lazarus :ccool:) :
on trouve, dans le fichier fpcup.lpr, à quatre endroits différents, la ligne writeln('Error : wrong command line options given:'); , ce qui, vous en conviendrez, n'est pas pratique pour savoir ce qui a fait planter et où.
J'ai donc modifié ces lignes en rajoutant simplement (1) à (4) après le mot "error" et je vous engage à faire de même, ce me fut trop utile ! (lignes 526, 545, 614 et 656).
Voilà.
Il ne me reste plus qu'à mettre tout ça en prod dans la vraie vie, ce qui va consister d'abord à supprimer les installations de fpc, fpcsrc et lazarus sur la machine physique, sacrilège !, pour ensuite court-circuiter l'outil d'installation des paquets (autre sacrilège, :mrgreen:) et ça devrait le faire.
Le seul problème que j'ai rencontré, c'est lors du patch du fichier fpreadtiff.pas : je m'étais noté dans un coin qu'après avoir modifié le fichier il suffisait de taper "make" et ça compilait de nouveaux .o et .ppu mais avec cette nouvelle installation, terminée la simplicité !
J'ai passé environ deux heures pour trouver toutes les options à rajouter à fpc (oui, au passage j'ai changé de compilo, la structure et les paramètres d'un Makefile me faisant trop pleurer), je m'en suis sorti mais je crains le pire s'il faut un jour patcher plusieurs fichiers qui se mordent la queue.
On verra bien.
En pj un zip contenant le fichier ini (plein de commentaires, c'est un peu brut de décoffrage, enfin, ça vous donnera une idée de ce que j'ai vécu :mouarf:) et le script, commenté également : Pièce jointe 191874
EDIT : y aura qu'à rajouter ça à la fin du script (non testé en vrai, mais en simulation c'est bon), et ça devrait régler ce problème de langue :
librement inspiré de # http://www.developpez.net/forums/d15...tring-fichier/Code:
2
3
4
5
6
7
8
9
10
11
Salut he ben ! tant as eu du courage tu crois que cela serai applicable sous Windows ? si juste par hasard je viens de tomber la dessus http://wiki.freepascal.org/LazSVNPkg
Je vais y jeter un oeil cela à l'air très intéressant :)
A+
Salut,
et merci pour ton retour.
Oui, surement, puisqu'il n'y aurait qu'à adapter le script que j'ai fourni à l'environnement Microsoft.Citation:
Envoyé par BeanzMaster
Tu nous diras.Citation:
Envoyé par BeanzMaster
Perso, je n'utilise l'outil SVN qu'à 1% de ses capacités, à savoir juste pour downloaded le dossier qui va bien, une fois celui-ci paramétré dans fpcup.ini.
Tout le reste est fait par fcpup.
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:
2
3
4
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... :aie:
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... :calim2:
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... :koi:
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. :ccool:
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. :weird:
